[Nml-wg] xml list examples

[Roman Łapacz]

Hi Jason,

W dniu 2010-12-09 15:07, Jason Zurawski pisze:
> 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.

Now it's clear to me what's 'c'. I'm OK with it.

>
>
>> 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 agree but the work on circuit monitoring which needs ordering in xml 
docs is ongoing and can not wait too long for the final decision 
(deadlines :)

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

I assure you I analysed the options that Aaron sent :) I don't agree 
that the use of attributes of collection namespace does not belong to 
the topic (I agree that for referencing the proposal presented by you is 
the best one but for ordering the solution of attribute namespace may be 
worth to consider). I would say it's an other additional option.

Cheers,
Roman

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