[Nml-wg] Extensability (was: Labels)

[Aaron Brown]

On May 9, 2012, at 6:11 PM, Freek Dijkstra wrote:

> Roman Łapacz wrote an example of his label proposal:
> 
>>  <nml:label>
>>    <nml:parameter name="type">c-vlan</nml:parameter>
>>    <nml:parameter name="value>42</nml:parameter>
>>  </nml:label>
>> 
>> 
>> By default, other namespaces than nml basic one are not needed but I
>> would not forbid them. Use of a set of nml:parameter elements (flat
>> structure) seems to be enough flexible to cover almost all possible
>> cases but I can imagine a very rare requirement to have a nested
>> structure inside nml:label, for example:
>> 
>>    <nml:label>
>>        <nml:paremeter name="type">xyz</nml:parameter>
>>        <nml-ext:something_1>
>>            <nml-ext:something_2>
>>                ...
>>            </nml-ext:something_2>
>>        </nml-ext:something_1>
>>    </nml:label>
>> 
>> (that is why I've added anyElement in the RNC snippet)
>> 
>> If you are 100% sure that such a requirement will not come up I'm fine
>> to remove this extension possibility.
> 
> My question to all: how to we want NML to be extensible?
> 
> In this particular use case I'm pretty confident that if we extend NML
> as in the above example, all parsers need to be rewritten/modified, and
> we will make this a "NML version 2" including the required change in
> (URL of) the NML base schema. Hence, this extensibility is not required
> for this NML version 1.
> 
> That said, I can imagine that someone will interweave third-part XML
> constructs. E.g., some software may add some policy attributes:
> 
>>    <nml:label>
>>        <nml:paremeter name="type">xyz</nml:parameter>
>>        <myauth:policy>
>>            <myauth:user>PSNC</myauth:user>
>>            <myauth:permission>allow-all-labels</myauth:permission>
>>        </myauth:policy>
>>    </nml:label>
> 
> Specific questions:
> 
> 1. Should we allow/support interweaving of third-part XML constructs in
> NML, or explicitly restrict/forbid that?

Logically, we should because the theory behind XML is that you can ignore stuff you don't know. On the other hand, most XML parsing is built around schema definitions and tend to barf if they hit things they don't understand, and don't offer a way of ignoring them.

> 2. We now define keywords for:
>  - relation type
>    <nml:Relation type="*">
>  - label parameter name
>    <nml:parameter name="*">
>  - label type
>    <nml:label><nml:parameter name="type">*</nml:parameter></nml:label>
>  - service type
>    <nml:Service type="*">
>  - adaptation type
>    (not defined in syntax yet)
> 
> These are clear and well-defined extensions, which is good.
> My question: would these extensions require a OGF standards action?
> Since none of these contain a namespace, a third party can not create
> them without the risk of a name-conflict.
>  - I don't think this will stop 3rd parties, leading to potential
>    name conflicts
>  - It requires the OGF to define a document for each technology
>    (each  label and each adaptation).
> 
> Is this what we want?

If we offer best practices in defining the syntax, e.g. "if you're defining a new type, it should be of the form '[organization description].[type description]'", that could decrease the chance of overlap. OGF could then define standardized versions.

Cheers,
Aaron

> 
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

Internet2 Spring Member Meeting
April 22-25, 2012 - Arlington, Virginia
http://events.internet2.edu/2012/spring-mm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120510/4e6b23f4/attachment-0001.html>