[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

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>.