I had a bit of time today to look more closely at the new XML output,
generated a few reports and perused the code. I had some thoughts and
comments and if anybody wants to run w/ them or work with me on them
it'd be much appreciated. In particular Guillaume &| Lionel...
Things I'd suggest, and perhaps Noah White (whom I recall was very well
versed in XML & friends) can comment as well:
- Within <config>: <global>, <scanner>, <server>, <plugins> should be
broken out instead of attributes. Especially since things like scanner,
server, and plugins are so dynamic.. and special characters should be
stored as codes & possible take advantage of CDATA (although it will
only cover two characters)..
- In the individual <plugin>, within the <plugins> section, we should be
sure to encode email addys and such properly. Special characters again,
etc. And, BTW, we should probably keep tag labels unique even though
they are nodes of different sections.
- Perhaps more descriptive labels should be used. I was particularly
confused at first look at the <ports> with the <port> embedded. And
again, encoding should be of note. What makes it funner yet is the fact
some descriptions and such already have encoded characters and DOS style
linefeeds.
- CDATA can be your friend.
A long long time ago in a galaxy far far away I was going to do I18N
bits and the big/neat part of that would be to redefine the way plugins
and descriptions are held. There was talk of wrapping things in a DBM,
yada-yada. The format for the actual bits was XML...
Anyhow, I got back to it recently and it might be nice if we (Guillaume,
Lionel, ..) could work together and get both sides to match up. It'd
give me motivation and a watching-eye to get less sleep and get more
work done, and perhaps improve both sides (input and output). Sound ok?
Attached is the beginnings of a schema for the storage format I was
thinking about. With comments and notes... take a look, let me know.
If you respond w/ the attachment make sure you only resend it to me. I'm
being bad enough by sending it to the list the first time. I can setup
homespace on packetknife.com for the files or Renaud might give us a
seperate CVS tree... anyhow.
Take care, -Ali
--
PGP 53F7FF5F -- 6662 5087 119D 8D18 8501 8A8D C583 97B6 53F7 FF5F
--
Only amateurs attack machines; professionals target people.
-- Bruce Schneier
<?xml version="1.0" encoding="utf-8"?>
<!-- =========================================================================
NESSUS_PLUGIN.XSD
Version 0.0.0
Revision Date 01/07/2002
Contributors ?
Copyright? Licensing?
========================================================================== -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en-US">
NESSUS_PLUGIN.XSD
Copyright?
Licensing?
</xsd:documentation>
</xsd:annotation>
<!-- <plugin> { Barf } </plugin> -->
<xsd:element name="plugin" type="pluginType"/>
<!-- Languages should be seperated out by file/directory/dbm but we shouldn't
try to make the schema track all of that. All the translations can be
bound together by the whoami field.
CDATA should be used in any field that may have special chars or extra
markup, say HTML. Keywords can be an exception, things should be no more
than, say, 3 words.
01/07/2002- I'm not sure I believe the above anymore. The fields should
be properly encoded. -Ali
Anything that doesn't need to be translated is optional. Do we want a
seperate schema for the base English version? So we can be as type
strong as possible? (ie. minOccurs="0") -Ali -->
<xsd:complexType name="pluginType">
<xsd:sequence>
<xsd:element name="whoami" type="whoamiType"/>
<xsd:element name="language" type="xsd:language"/>
<xsd:element name="category" type="categoryType"/>
<xsd:element name="keywords" type="keywordsType"/>
<xsd:element name="summary" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="description" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="metrics" type="metricsType" maxOccurs="unbounded"/>
<xsd:element name="workaround" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="fix" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="crossref" type="crossrefType" maxOccurs="unbounded"/>
<xsd:element name="platform" type="platformType"/>
<xsd:element name="nasl" type="xsd:string"/> <!-- CDATA? -->
</xsd:sequence>
</xsd:complexType>
<!-- <whoami id="#" date="YYYY-MM-DD"/> -->
<xsd:complexType name="whoamiType">
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
<xsd:attribute name="date" type="xsd:date" use="required"/>
<!-- Do we want a sub-revision field to accompany date? -Ali -->
</xsd:complexType>
<!-- <category type="category"/> -->
<xsd:complexType name="categoryType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- categories -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
<!-- <keywords>
<default>default</default>
<words>Get your groove on.</words>
<words>However many times.</words>
</keywords> -->
<xsd:complexType name="keywordsType">
<xsd:sequence>
<xsd:element name="default" type="xsd:string"/>
<xsd:element name="words" type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- <metric type="metric">value</metric> -->
<xsd:complexType name="metricsType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- metrics -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:element name="value">
<xsd:simpleType> <!-- values -->
<xsd:restriction base="xsd:positiveInteger">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="4"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:complexType>
<!-- <crossref type="crossref">value</crossref> -->
<xsd:complexType name="crossrefType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- crossref -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- Strongly typed by created a regex for each type above? -Ali -->
<xsd:element name="value" type="xsd:string"/>
</xsd:complexType>
<!-- <platform>
<os>OS</os>
<proc>proc</proc>
< .. >
</platform> -->
<xsd:complexType name="platformType">
<xsd:element name="os">
<xsd:simpleType> <!-- OSes -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="">
</xsd:element> <!-- Fill these in. -Ali -->
</xsd:complexType>
</xsd:schema>
generated a few reports and perused the code. I had some thoughts and
comments and if anybody wants to run w/ them or work with me on them
it'd be much appreciated. In particular Guillaume &| Lionel...
Things I'd suggest, and perhaps Noah White (whom I recall was very well
versed in XML & friends) can comment as well:
- Within <config>: <global>, <scanner>, <server>, <plugins> should be
broken out instead of attributes. Especially since things like scanner,
server, and plugins are so dynamic.. and special characters should be
stored as codes & possible take advantage of CDATA (although it will
only cover two characters)..
- In the individual <plugin>, within the <plugins> section, we should be
sure to encode email addys and such properly. Special characters again,
etc. And, BTW, we should probably keep tag labels unique even though
they are nodes of different sections.
- Perhaps more descriptive labels should be used. I was particularly
confused at first look at the <ports> with the <port> embedded. And
again, encoding should be of note. What makes it funner yet is the fact
some descriptions and such already have encoded characters and DOS style
linefeeds.
- CDATA can be your friend.
A long long time ago in a galaxy far far away I was going to do I18N
bits and the big/neat part of that would be to redefine the way plugins
and descriptions are held. There was talk of wrapping things in a DBM,
yada-yada. The format for the actual bits was XML...
Anyhow, I got back to it recently and it might be nice if we (Guillaume,
Lionel, ..) could work together and get both sides to match up. It'd
give me motivation and a watching-eye to get less sleep and get more
work done, and perhaps improve both sides (input and output). Sound ok?
Attached is the beginnings of a schema for the storage format I was
thinking about. With comments and notes... take a look, let me know.
If you respond w/ the attachment make sure you only resend it to me. I'm
being bad enough by sending it to the list the first time. I can setup
homespace on packetknife.com for the files or Renaud might give us a
seperate CVS tree... anyhow.
Take care, -Ali
--
PGP 53F7FF5F -- 6662 5087 119D 8D18 8501 8A8D C583 97B6 53F7 FF5F
--
Only amateurs attack machines; professionals target people.
-- Bruce Schneier
<?xml version="1.0" encoding="utf-8"?>
<!-- =========================================================================
NESSUS_PLUGIN.XSD
Version 0.0.0
Revision Date 01/07/2002
Contributors ?
Copyright? Licensing?
========================================================================== -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en-US">
NESSUS_PLUGIN.XSD
Copyright?
Licensing?
</xsd:documentation>
</xsd:annotation>
<!-- <plugin> { Barf } </plugin> -->
<xsd:element name="plugin" type="pluginType"/>
<!-- Languages should be seperated out by file/directory/dbm but we shouldn't
try to make the schema track all of that. All the translations can be
bound together by the whoami field.
CDATA should be used in any field that may have special chars or extra
markup, say HTML. Keywords can be an exception, things should be no more
than, say, 3 words.
01/07/2002- I'm not sure I believe the above anymore. The fields should
be properly encoded. -Ali
Anything that doesn't need to be translated is optional. Do we want a
seperate schema for the base English version? So we can be as type
strong as possible? (ie. minOccurs="0") -Ali -->
<xsd:complexType name="pluginType">
<xsd:sequence>
<xsd:element name="whoami" type="whoamiType"/>
<xsd:element name="language" type="xsd:language"/>
<xsd:element name="category" type="categoryType"/>
<xsd:element name="keywords" type="keywordsType"/>
<xsd:element name="summary" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="description" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="metrics" type="metricsType" maxOccurs="unbounded"/>
<xsd:element name="workaround" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="fix" type="xsd:string"/> <!-- CDATA? -->
<xsd:element name="crossref" type="crossrefType" maxOccurs="unbounded"/>
<xsd:element name="platform" type="platformType"/>
<xsd:element name="nasl" type="xsd:string"/> <!-- CDATA? -->
</xsd:sequence>
</xsd:complexType>
<!-- <whoami id="#" date="YYYY-MM-DD"/> -->
<xsd:complexType name="whoamiType">
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
<xsd:attribute name="date" type="xsd:date" use="required"/>
<!-- Do we want a sub-revision field to accompany date? -Ali -->
</xsd:complexType>
<!-- <category type="category"/> -->
<xsd:complexType name="categoryType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- categories -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
<!-- <keywords>
<default>default</default>
<words>Get your groove on.</words>
<words>However many times.</words>
</keywords> -->
<xsd:complexType name="keywordsType">
<xsd:sequence>
<xsd:element name="default" type="xsd:string"/>
<xsd:element name="words" type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- <metric type="metric">value</metric> -->
<xsd:complexType name="metricsType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- metrics -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:element name="value">
<xsd:simpleType> <!-- values -->
<xsd:restriction base="xsd:positiveInteger">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="4"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:complexType>
<!-- <crossref type="crossref">value</crossref> -->
<xsd:complexType name="crossrefType">
<xsd:attribute name="type" use="required">
<xsd:simpleType> <!-- crossref -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- Strongly typed by created a regex for each type above? -Ali -->
<xsd:element name="value" type="xsd:string"/>
</xsd:complexType>
<!-- <platform>
<os>OS</os>
<proc>proc</proc>
< .. >
</platform> -->
<xsd:complexType name="platformType">
<xsd:element name="os">
<xsd:simpleType> <!-- OSes -->
<xsd:restriction base="xsd:string">
<xsd:enumeration value=""/> <!-- Fill these in. -Ali -->
<xsd:enumeration value=""/>
<xsd:enumeration value=""/>
<!-- .. -->
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="">
</xsd:element> <!-- Fill these in. -Ali -->
</xsd:complexType>
</xsd:schema>