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.