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