Hi Freek; On 8/16/11 9:06 AM, thus spake Freek Dijkstra:
Jason Zurawski 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>
I think you mean this instead:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relation type="serialcompound"> ... </nml:relation> </nml:link>
Yes, you are right of course -- thanks for catching that.
I agree with Roman, the use of the 'relations' element is really not necessary here.
I am still not clear why you believe this element is necessary. It is a 'grouping' concept from what I can tell, but this does not add any inheritance into the sub elements except that of parent/child. The concept of namepsaces gives you the inheritance that I think you want.
The base element (<nml:relation type="serialcompound">) has the problem that it is hard to create a meaningful syntax validator.
What syntax do you need to validate that would be drastically different than 'nml:relation'. If you can cite examples, we would all be happy to read and critique them.
The subelement (<nmlserialcompound:relation>) has the problem all parser would need to know about the nmlserialcompound schema in advance, which hinders extensibility. (*)
See my prior mail - if you rely only on syntactic validation yes, it would be rejected. If you have a rich set of semantic validation, you can insert rules that help you in this regard. E.g. the semantic rules can be constructed so that the hierarchy is well defined, and the service knows that 'nmlserialcompound:relation' is just a specific form of 'nml:relation', thus some of the meaning can be extracted. So far it appears that you are trying to get all of the benefits of semantic validation directly into the schema level. I will point out that this absolutely destroys extensibility. If the goal is to make a schema that can be extended into other use cases beyond what our tiny minds can imagine, we need to be sure that we are not locked in to a schema that has too many rules that would hinder the ability to alter it for other use cases.
The subelement with extra parent element (<nml:relations><nmlserialcompound:relation>) does not have either of these two problems.
I still do not understand how you are able to draw the conclusion that by adding in one more element, you eliminate all of the ills you note above. You do not defeat needing to be aware of the schema beforehand, and you do not add a meaningful semantic rule into the schema. This really just seems like the addition of a new element to add an illusion of semantic meaning. Thanks; -jason
Which of these 3 statements do you disagree with?
Freek
(*) I'm aware about some subtleties regarding my statement on the disadvantage of<nmlserialcompound:relation> -- a parser may still ignore it, not knowing it is a relation subclass -- I'm most happy to elaborate on that if you think that<nmlserialcompound:relation> is a better option than<nml:relations><nmlserialcompound:relation>.