[Nml-wg] NML-NSI integration

[Roman Łapacz]

W dniu 2012-02-17 16:53, Jerry Sobieski pisze:
> Guys-
>
> If you are considering which parsers will process the constructs then 
> you are already way past where you need to be.

No, no, we are not talking about parser implementations but how nml 
elements could be interpreted.

Roman

>
> I would implore you to make the specification so simple that the 
> standard is not based on nor is concerned about parser implementations.
>
> Jerry
>
>
>
> On 2/17/12 10:45 AM, Roman Łapacz wrote:
>> W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
>>> Hi all,
>>>
>>> A port can have many properties. It can be abstract, Ethernet, (NSI)
>>> domain boundary port, have restricted access, be part of a link bundle.
>>>
>>> What I want to avoid is having to deal with namespaces and objects such
>>> as<nml-nsi-ethernet-restricted-lacp:port>
>>>
>>>> If we allow adding new tags as extensions in any place in the 
>>>> structure
>>>> then we don't have too much control over the structure. Generic 
>>>> parsers
>>>> will not know how to interpret such unexpected (not included in the 
>>>> base
>>>> NML schema) changes. On the contrary, namespaces as extensions allow
>>>> parsers to, at least, understand their standard properties, others 
>>>> would
>>>> be ignored. The structures defined in the base NML schema are still
>>>> followed. (Of course it is possible to define a schema in such way 
>>>> that
>>>> any element could be inserted in any place but I don't think it's the
>>>> right direction).
>>> The RNC schema you created last year DID allow arbitrary elements 
>>> inside
>>> NML elements.
>>>
>>> I think I misunderstand you. In particular, I do not understand the
>>> sentence "namespaces as extensions allow parsers to, at least,
>>> understand their standard properties."
>>>
>>
>> a very simple example
>>
>> <nml-ext:x>
>> <nml:y></nml:y>
>> <nml-ext:z></nml-ext:z>
>> </nml-ext:x>
>>
>> A parser which does not understand the nml-ext extension/namespace 
>> would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.
>>
>>
>> Roman
>>
>>
>>> Are you talking about chameleon namespaces?
>>>
>>> I assume that:
>>>
>>> * NML elements can contain arbitrary child elements, from the NML or
>>> other namespace
>>> * if a parser encounters an unknown element from a known namespace, it
>>> should stop and return an error
>>> * if a parser encounters an element from a unknown namespace, it should
>>> ignore it (or -if we define chameleon namespaces- interpret as if it 
>>> was
>>> part of the base namespace)
>>> (Note that in this case, I'm unclear how a parser should distinguish
>>> between a chameleon namespace and a proprietary namespace which can
>>> safely be ignored.)
>>>
>>> Could you perhaps give an example of a message containing NML and NSI
>>> information, and explain how a parser which only understands NML sees
>>> it, and how a parsers understands both NML and NSI sees it, and if
>>> either should ignore unknown elements or stop and return an error?
>>>
>>> Freek
>>> _______________________________________________
>>> nml-wg mailing list
>>> nml-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nml-wg
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg