Hi, On Thu, Dec 2, 2010 at 4:31 PM, Jason Zurawski <zurawski@internet2.edu>wrote:

Hi All;

...

On the call, I was asked to send some examples of how we've done ordered

On 12/2/10 4:16 PM, Aaron Brown wrote: lists in XML before. Looking through various xml bits, I found a few different ways that we've sorted lists.

...

1) a numerical 'id' element:

<nmwg-cp:hop id=”0”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”1”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”2”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”3”> .... </nmwg-cp:hop>

2) explicit 'next' pointers:

<path> <hop id="internet2-1"> .... <nextHop>esnet-1</nextHop> </hop> <hop id="esnet-1"> .... <nextHop>bnl-1</nextHop> </hop> <hop id="bnl-1"> .... </hop> </path>

As discussed on the call one would need to have a parser that respected 'document order' to ensure the next sequence is correct. Modern XML parsers feature this (e.g. LibXML), but its not a part of the XML standard itself so there is no guarantee you will find it in all implementations.

If an attribute/element 'firstHop' is added to the <path> element above, respecting document order is no longer required: <path firstHop="internet2-1"> <hop id="internet2-1"> .... <nextHop>esnet-1</nextHop> </hop> .... </path> Best, Guilherme Thanks;

-jason

...

3) implicit document ordering (this data corresponds to a traceroute. there would be more 'datum' elements in a real traceroute instance each of which corresponds to a single traceroute probe sent. This was cleaned up to make it easier to read):

<nmwg:data id="data.AAAFFF.0" metadataIdRef="meta.AAAFFF" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> <traceroute:datum hop="198.129.254.29" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="1" value="0.135" valueUnits="ms"/> <traceroute:datum hop="134.55.219.10" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="2" value="1.14" valueUnits="ms"/> <traceroute:datum hop="134.55.217.2" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="3" value="37.212" valueUnits="ms"/> <traceroute:datum hop="134.55.209.98" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="4" value="1.616" valueUnits="ms"/> <traceroute:datum hop="134.55.220.49" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="5" value="28.643" valueUnits="ms"/> <traceroute:datum hop="134.55.209.46" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="6" value="41.773" valueUnits="ms"/> <traceroute:datum hop="134.55.221.58" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="7" value="52.36" valueUnits="ms"/> <traceroute:datum hop="134.55.218.101" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="8" value="52.373" valueUnits="ms"/> <traceroute:datum hop="198.124.252.141" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="9" value="52.311" valueUnits="ms"/> </nmwg:data>

Cheers, Aaron

---

nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg

On 03/12/2010 00:11, Jason Zurawski wrote:

Freek/Jerone: what does RDF do (or would could RDF do) to do the same thing?

(Just a reminder, my name is Jeroen, not Jerone ;)) I've personally not used it before, but accoding to the RDF schemathere are the following options (see example below): - rdf:Bag containing numbered items (rdf:_1, rdf:_2, ...) which are actually taken as unordered items. - rdf:Bag containing unnumbered items like HTML lists (rdf:li) - rdf:Seq contains unnumbered items like HTML lists (rdf:li), which are supposed to be read in order. I must say I'm a bit amazed by the last option since XML doesn't seem to support ordering. For completeness, there's also a rdf:Alt class for providing alternate options, which also uses rdf:li Jeroen. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:lib="http://www.zvon.org/library"> <lib:Author about="RD"> <lib:firstName>Roald</lib:firstName> <lib:surname>Dahl</lib:surname> <lib:books> <rdf:Bag> <rdf:_1 resource="Matilda"/> <rdf:_2 resource="The BFG"/> </rdf:Bag> </lib:books> </lib:Author> <rdf:Description about="JC"> <rdf:type resource="http://www.zvon.org/library/Author"/> <lib:firstName>Joseph</lib:firstName> <lib:surname>Conrad</lib:surname> <lib:books> <rdf:Bag> <rdf:li resource="Heart of Darkness"/> <rdf:li resource="Lord Jim"/> <rdf:li resource="The Secret Agent"/> </rdf:Bag> </lib:books> </rdf:Description> <lib:Book about="Matilda" lib:pages="240"> <lib:copy> <rdf:Seq> <rdf:li resource="M124"/> <rdf:li resource="M125"/> <rdf:li resource="M126"/> </rdf:Seq> </lib:copy> </lib:Book> <rdf:Description about="The BFG" lib:pages="208"> <rdf:type resource="http://www.zvon.org/library/Book"/> <lib:copy rdf:resource="T458"/> </rdf:Description> <lib:Book about="Heart of Darkness" lib:pages="110"> <lib:copy rdf:resource="H16"/> </lib:Book> <lib:Book about="Lord Jim" lib:pages="314"> <lib:copy rdf:resource="L187"/> </lib:Book> <lib:Book about="The Secret Agent" lib:pages="249"> <lib:copy rdf:resource="T360"/> </lib:Book> </rdf:RDF>

W dniu 2010-12-04 18:06, Freek Dijkstra pisze:

romradz@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?)? 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). 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? 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

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

W dniu 2010-12-09 16:29, Jason Zurawski pisze:

On 12/9/10 10:06 AM, Roman Łapacz wrote:

...

...

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.

I am not sure I follow why attributes of different namespaces applies to the proposal to order XML elements. If you think they are related thats fine, but if memory serves me these were two different topics at OGF 30.

To be honest I don't remember that attributes of a different namespace was discussed in the context of ordered list. I would say that was discussed in the context of referencing but I'm not sure. Presented proposal of attribute in collection namespace was the result of my thinking how it could be done without adding new elements which don't represent topology but only ordering (they are not neccessary for topology description but to deal with the problem in xml implementations). Cheers, Roman

-jason