Comments follow original text: Roman Łapacz wrote:
So far, we have seen these two proposals:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relation type="serialcompound"> ... </nmlserialcompound:relation> </nml:link>
and:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:link>
The advantage of the first syntax is that it is very easily extendable, and it is still obvious for a parser to understand that it is some kind of nml:relation, even if the particular type of relation is not known by the parser.
The advantage of the second syntax is that it is easy to create a meaningful validator for each specific nml:relation.
I dislike both syntaxes, and was hoping for a syntax that would provide both benefits.
If I'm correct, the following syntax will do just that:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relations> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:relations> </nml:link>
This adds a parent element to the relation elements, signifying that <nmlserialcompound:relation> is indeed a nml:relation. So even a parser that has no knowledge about this particular nml:relation still knows it's base syntax, while a parser that understands the details can still use an meaningful syntax validator (such as XSD) to make sure the syntax is correct.
The solution with namespaces gives you that (nmlserialcompound:relation inherits from the base nml:relation). nml:relations only complicates the xml structure without giving too much.
You mean you prefer the following?: <nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:link> How should the parser know that nmlserialcompound:relation inherits from the base nml:relation? I can think of two things: - Because the parser has knowledge of the schema definition - Because the parser assumes that all elements named "relation" are subclasses of nml:relation. The problem with the first is that it requires all parsers known all schemas beforehand. I see a risk with backward compatibility after future extensions if that is required. The problem with the second is that this fails if some schema (for whatever reason) includes a namespace where relation has a different meaning. Eg: family:relation or work:relation. For this reason, including the extra nesting with <nml:relations> seems to me a relative simple solution to solve these problems. Regards, Freek