[Nml-wg] xml list examples

[Jason Zurawski]

On 12/9/10 7:33 AM, Roman Łapacz wrote:
> W dniu 2010-12-04 18:06, Freek Dijkstra pisze:
>> romradz at man.poznan.pl wrote:
>>
>>> during the OGF30 it was said that the namespace for attributes is not a
>>> good idea (may only complicate things).
>> It's just unusual for regular XML (it is common for RDF).
>> My opinion is that if we can avoid it, that's nice to have (to ease the
>> learning curve for people who never saw it before), but it's not very
>> important (I presume all XML libraries support it).
>>
>>> Let's assume we had a separate namespace for at least 2 attributes (type,
>>> item) to deal with collections like list, map and set.
>>>
>>> Examples:
>>>
>>> <x collection:type="list"
>>> xmlns:collection="http://ggf.org/ns/collections">
>>>      <y collection:item="1">value</y>
>>>      <y collection:item="2">value</y>
>>>      <y collection:item="3">value</y>
>>> </x>
>> [...]
>>
>>> Collection namespace and its attributes would not be a part of NML, just a
>>> definition which could be used by NML and other standards (for example,
>>> NMC). Only when collection structures are needed. This way NML would not
>>> have to define ordering (format issue) but focus on topology elements and
>>> their relations.
>> This has my personal preference.
>>
>> This is in fact basically the same question as this one ("where to put
>> XML attributes that are not specific to NML):
>>
>>> Question 2b. What attribute to use for references in XML?
>>> a) id and idref in NM-WG namespace
>>> b) id and idref in NML base namespace
>>> c) id and idref in NML Ethernet namespace
>>> d) id and idref in new (OGF) namespace (created for just these attribs)
>>> e) about and resource in RDF namespace
>> (see topic "Identifier" previous month).
>>
>> Your solution is solution d.
>
> My proposal is for ordering not referencing. Here I would vote for 'b'
> or 'a' (prefer b). Jason., why see 'c' (it doesn't seem to be a general
> solution; only for Ethernet?)?


To make my point, I am going to need to go into a longer example, 
apologies for not being more brief.

A quick lesson for everyone on how the RNC inclusions principals work. 
I am looking at the examples in 
http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/schema/rnc/topo/ as I 
type this:

  - The first file to look at should be the 'types' file.  It contains 
all of the generic elements and attributes that we will use in the 
remainder of the schema.  'Id' and 'IdRef' attributes, also elements 
such as 'lifetime'.  Note that in this file we are not specifying a 
default namespace for attributes or elements; this is done on purpose. 
Elements and attributes that do not have a namespace can become 
'chameleons' and take on the namespace of whatever they are used in, see 
here for a better description: 
http://books.xmlschemata.org/relaxng/relax-CHP-11-SECT-5.html

  - The base schema would create the original definition for elements 
like 'link' and the other first order elements of NML.  We also 
establish the base namespace 
('http://ogf.org/schema/network/topology/base/20070707/').  The base 
schema 'includes' the types file, by doing this:

> # External schema files
>  include "nmtypes.rnc"

This allows us to use all prior definitions, and they assume the default 
namespace of the element they are used in (e.g. 'chameleons').  For 
example this statement:

>  BaseLink = element link { BaseLinkContent }
>  BaseLinkContent =
>    Identifier?
>    & IdReference?

Allows us to make an actual XML element:

>   <nmtb:link xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070707/" id="something" idRef="something_else" />

Attributes that do not specify a namespace are assumed to posses the 
same namespace as the element that encloses them.  We could also say it 
this way (to explicitly place namespaces on the attributes):

>   <nmtb:link xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070707/" nmtb:id="something" nmtb:idRef="something_else" />

  - Subsequent schemas that are 'more specific than the base', e.g. the 
notion of the layers or the technologies, no longer directly include the 
base schema.  This was a mistake we made early on with the first 
topology schema - as much as we want to think that XML and XML schemata 
work like OO programming techniques where we can simply re-cast things 
into new namespaces as needed, they don't.  The chameleon design is the 
closest thing that gets us to this and is much easier to work with from 
an implementation point of view.

Looking at one of the other schemas (e.g. _l3) you will see it follows a 
similar pattern to the base.  We include the types, and define the guts 
that make a l3 link a l3 link.


To get back to Roman's question, and Freek's original proposal - I do 
not see using the 'Ethernet' version of the attributes the same way as 
you two appear to be viewing it.  Other than the different namespace 
that is involved when we happen to reference it in some specific 
incarnation, it's the same attribute using the same original definition. 
  If we are trying to 'recycle' and save effort, I would note that this 
is the ideal way to do so since we never re-define an attribute in more 
than one place.

I do believe that the following example creates a hardship and makes the 
schema more prone to errors when we try to involve additional namespaces:

> <nmtl3:link xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070707/"
>             xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070707/"
>             nmtb:id="something" nmtb:idRef="something_else" />

This is why 'c' is the choice that I would prefer to see.


> One more comment about adding a separate namespace for ordered list. NML
> schema does not have to include definitions of additional elements for
> that ('next' or something like that). If a xml library supports ordering
> then an attribute of collection namespace could be ignored. Clean and
> simple solution (and independent of types of ordered elements).


While some XML libraries may support ordering, it is not built into the 
spec, and therefore something we cannot count on.  If we are to design 
an unambiguous way to model this information, we must build it on the 
underlying technologies as they are designed - the XML spec doesn't 
allow for ordering, therefore we can't expect to be able to use it.


> Can we make a final decision what is going to be used for ordered list?
> Freek, what do you think to make a deadline for it?


I would rather get this 'right' than get this 'done fast'.  I am not 
convinced that we have carefully weighed the options that Aaron 
originally sent, since its only been about a week.  In fact if you look 
above, they are no longer present in this email thread.  We have drifted 
off-topic into other unrelated areas including the above discussion 
about attribute namespaces.

If we are going to move this forward we need to stay on topic.  I will 
re-reply to Aaron's original.

Thanks;

-jason


> regards.
> Roman
>
>
>> However, there is no consensus on this topic yet. Please correct me, but
>> I thought the opinions expressed were:
>>
>>> Freek:  a, d, e
>>> Jeroen: b
>>> Jason:  c
>> My current stance is that whoever has the time/effort to create the
>> schema gets to decide :)
>>
>> Regards,
>> Freek