Hi all, After writing our ideas on identifiers down, I still have a five smaller questions. Quotes are from the meeting notes (http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.nml-wg/doc...):
Rough consensus on: - http://schemas.ogf.org/nml/base/2013/10/ (Jason's proposal)
Question 1. Should the schema end with a / or #? a) http://schemas.ogf.org/nml/base/2013/10 (common for XML) b) http://schemas.ogf.org/nml/base/2013/10/ (current proposal) c) http://schemas.ogf.org/nml/base/2013/10# (common for RDF) For XML I don't think it makes any difference; for RDF, I think it should be b or c. (We may decide on a different namespace for XML and RDF, but I propose not to do that unless there are compelling reasons to do so). Further recap from the meeting notes:
In Catania NML decided on Instance identifiers format: urn:ogf:network:<domain part>:<local part> <local> is opaque only processed by end parts GLIF also agreed to use this format.
Richard & Freek did put together a doc for the IETF RFC to define the URI Freek has translated to xml but he needs to consult Joel on web site details
Case insensitive: RFC says have to specify case sensitive/insensitive So need to define urn:ogf: at OGF level Then :network: and the rest case insensitive. i.e. have to define the lexical equivalence.
Rough consensus on: - Different objects eg link and port MUST have different identifiers - instance identifiers are case insensitive - instance identifiers are non-international (thus an URI instead of IRI) - URI are not restricted by length, other than possible restrictions by RFC 2141 (the current GLIF recommendation is max 48 to 80 bytes)
I forgot to mention in the notes that we a discussion how to refer to identifiers. (see slides 14-18 in http://forge.gridforum.org/sf/go/doc16081) - RDF uses the attributes rdf:about and rdf:resource - NM-WG uses the attributes id and idref - The BUILT-IN XML ID and IDREF attributes can not be used, since they only work within a document. We had a discussion if we should re-use the id and idref from the NM working group (formally: re-use the attributes in the http://ggf.org/ns/nmwg/base/2.0/ namespace) or are to redefine these attributes again. I forgot what the consensus was. Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref We decided on the urn:ogf:network:example.net:opaque-identifier syntax. We have not yet defined what characters should be allowed in the opaque identifier part. We have the following options: Allowed characters: GLIF: A-Z a-z 0-9 - . RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex unreserved: A-Z a-z 0-9 - . _ ~ where %hex is a percentage-encoding. E.g. %2E. - unreserved and pchar are definitions from RFC 3986, which defines URIs - GLIF is what is defined in the GLIF working group. This is extremely limited (: and _ are not allowed). - RFC 2141 is what is currently allowed in a URN. (this list excludes 4 "reserved" characters which are in the definition for future use.) - RFC 2141 is currently being revised. It is very likely that & and ~ will be allowed, making the definition equal to that of pchar. - unreserved is similar to the current GLIF list. - Note that the following characters are NEVER allowed: % / ? # [ ] \ " < > [ ] ^ ` { | } Question 3. What characters are allowed in <opaque string>? a) GLIF: A-Z a-z 0-9 - . b) unreserved: A-Z a-z 0-9 - . _ ~ c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex The current schema states that ALL Network Objects MUST have an identifier. This is very strict. For example, even a network object that is never referenced MUST still have an ID. Thus the following is NOT allowed: <nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C"> <nml:link> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/> </nml:relation> </nml:link> <nml:link> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/> </nml:relation> </nml:link> </nml:bidirectional> Instead, everything MUST be named, like so: <nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C"> <nml:link id="urn:ogf:network:es.net:link_A_to_C"> <!-- ADDED id --> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/> </nml:relation> </nml:link> <nml:link id="urn:ogf:network:es.net:link_C_to_A"> <!-- ADDED id --> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/> </nml:relation> </nml:link> </nml:bidirectional> Question 4. MUST all object have an id? a) All Network Objects MUST have an identifier. a) All Network Objects SHOULD have an identifier. "SHOULD" means that an identifier may be left out, but only if it is clear what the consequences are (in this case: the result can not be referred to.) The current schema states that the Syntax of the identifier MUST follow the urn:ogf:network syntax. This might make future compatibility harder (e.g. when trying to combine it with other protocols; I can imagine that in the future other naming schema's may be developed). Question 5. MUST urn:ogf:network syntax be used? a) All identifiers MUST follow the urn:ogf:network syntax b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network syntax c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network syntax (some more variants are possible) Regards, Freek
My own opinion below.
Question 1. Should the schema end with a / or #? a) http://schemas.ogf.org/nml/base/2013/10 (common for XML) b) http://schemas.ogf.org/nml/base/2013/10/ (current proposal) c) http://schemas.ogf.org/nml/base/2013/10# (common for RDF)
Either b or c. (a may be a problem for RDF).
Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref
No big prefence. In order: a, c, or b (b lowest preference because I don't want to redefine again if we create technology-specific schemata,. e.g. for Ethernet, OTN, IP, etc.)
Question 3. What characters are allowed in <opaque string>? a) GLIF: A-Z a-z 0-9 - . b) unreserved: A-Z a-z 0-9 - . _ ~ c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex
Whatever will be defined in rfc2141bis, thus d or c. a or b miss a : and are too limited for that reason.
Question 4. MUST all object have an id? a) All Network Objects MUST have an identifier. b) All Network Objects SHOULD have an identifier.
b. Use it unless there is compelling reason not to.
Question 5. MUST urn:ogf:network syntax be used? a) All identifiers MUST follow the urn:ogf:network syntax b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network syntax c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network syntax (some more variants are possible)
b. Use it, unless there is compelling reason not to. Allow other syntax for forward compatibility. (e.g. I can imagine that in the future instead of using the FQDN or AS number, we have another method to identify domains, and we allow another type of URN). Freek
On 7 nov. 2010, at 20:23, Freek Dijkstra <Freek.Dijkstra@sara.nl> wrote:
My own opinion below.
Question 1. Should the schema end with a / or #? a) http://schemas.ogf.org/nml/base/2013/10 (common for XML) b) http://schemas.ogf.org/nml/base/2013/10/ (current proposal) c) http://schemas.ogf.org/nml/base/2013/10# (common for RDF)
Either b or c. (a may be a problem for RDF).
B seems to be the most interoperable solution.
Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref
No big prefence. In order: a, c, or b (b lowest preference because I don't want to redefine again if we create technology-specific schemata,. e.g. for Ethernet, OTN, IP, etc.)
I thought we decided on B? To me it seems very weird to reuse NM-WG namespace for something trivial as this and for that reason almost ridiculous to create a dedicated namespace for that.
Question 3. What characters are allowed in <opaque string>? a) GLIF: A-Z a-z 0-9 - . b) unreserved: A-Z a-z 0-9 - . _ ~ c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex
Whatever will be defined in rfc2141bis, thus d or c. a or b miss a : and are too limited for that reason.
I think we implicitly decided on C when we discussed the UTF-8 discussion... IIRC, we decided to follow the RFC syntax for urns.
Question 4. MUST all object have an id? a) All Network Objects MUST have an identifier. b) All Network Objects SHOULD have an identifier.
b. Use it unless there is compelling reason not to.
No real preference, but I can see that in some cases you don't want to do that.
Question 5. MUST urn:ogf:network syntax be used? a) All identifiers MUST follow the urn:ogf:network syntax b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network syntax c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network syntax (some more variants are possible)
b. Use it, unless there is compelling reason not to. Allow other syntax for forward compatibility. (e.g. I can imagine that in the future instead of using the FQDN or AS number, we have another method to identify domains, and we allow another type of URN).
Why do we want to restrict IDs to the urn namespace? IMO we want to have only one restriction: the ID must be globally unique, and it is up to the originator to come up with one that can be reasonably expected to be unique. The urn syntax makes it easy to do that, but other resources that are described in RDF may end up in a network topology description in some way, and these will not always use that syntax. I guess that means I vote for C. Jeroen.
Freek/All; On 11/7/10 2:16 PM, Freek Dijkstra wrote:
Hi all,
After writing our ideas on identifiers down, I still have a five smaller questions.
Quotes are from the meeting notes (http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.nml-wg/doc...):
Rough consensus on: - http://schemas.ogf.org/nml/base/2013/10/ (Jason's proposal)
Question 1. Should the schema end with a / or #? a) http://schemas.ogf.org/nml/base/2013/10 (common for XML) b) http://schemas.ogf.org/nml/base/2013/10/ (current proposal) c) http://schemas.ogf.org/nml/base/2013/10# (common for RDF)
For XML I don't think it makes any difference; for RDF, I think it should be b or c. (We may decide on a different namespace for XML and RDF, but I propose not to do that unless there are compelling reasons to do so).
b) is what we use currently in the perfSONAR/NMC world. Ex: https://svn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-LookupService/...
Further recap from the meeting notes:
In Catania NML decided on Instance identifiers format: urn:ogf:network:<domain part>:<local part> <local> is opaque only processed by end parts GLIF also agreed to use this format.
Richard& Freek did put together a doc for the IETF RFC to define the URI Freek has translated to xml but he needs to consult Joel on web site details
Case insensitive: RFC says have to specify case sensitive/insensitive So need to define urn:ogf: at OGF level Then :network: and the rest case insensitive. i.e. have to define the lexical equivalence.
Rough consensus on: - Different objects eg link and port MUST have different identifiers - instance identifiers are case insensitive - instance identifiers are non-international (thus an URI instead of IRI) - URI are not restricted by length, other than possible restrictions by RFC 2141 (the current GLIF recommendation is max 48 to 80 bytes)
I forgot to mention in the notes that we a discussion how to refer to identifiers.
(see slides 14-18 in http://forge.gridforum.org/sf/go/doc16081)
- RDF uses the attributes rdf:about and rdf:resource - NM-WG uses the attributes id and idref - The BUILT-IN XML ID and IDREF attributes can not be used, since they only work within a document.
We had a discussion if we should re-use the id and idref from the NM working group (formally: re-use the attributes in the http://ggf.org/ns/nmwg/base/2.0/ namespace) or are to redefine these attributes again. I forgot what the consensus was.
Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref
As I stated in person (but will restate for this list) its uncommon to try and associate attributes with a specific namespace other than what is associated with the parent element. E.g.: <ns:element attribute="something" /> Implies that 'attribute' is in the 'ns' namespace. It is uncommon to see this: <ns:element ns2:attribute="something" /> But it is possible. I think b) makes the most sense; we do this in NM/NMC now.
We decided on the urn:ogf:network:example.net:opaque-identifier syntax.
We have not yet defined what characters should be allowed in the opaque identifier part. We have the following options:
Allowed characters: GLIF: A-Z a-z 0-9 - . RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * '& %hex unreserved: A-Z a-z 0-9 - . _ ~
where %hex is a percentage-encoding. E.g. %2E.
- unreserved and pchar are definitions from RFC 3986, which defines URIs - GLIF is what is defined in the GLIF working group. This is extremely limited (: and _ are not allowed). - RFC 2141 is what is currently allowed in a URN. (this list excludes 4 "reserved" characters which are in the definition for future use.) - RFC 2141 is currently being revised. It is very likely that& and ~ will be allowed, making the definition equal to that of pchar. - unreserved is similar to the current GLIF list. - Note that the following characters are NEVER allowed: % / ? # [ ] \ "< > [ ] ^ ` { | }
Question 3. What characters are allowed in<opaque string>? a) GLIF: A-Z a-z 0-9 - . b) unreserved: A-Z a-z 0-9 - . _ ~ c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * '& %hex
I believe we should use the approach that is going to be supported the most widely, in parsing tools/libraries and what is most closely matched to GLIF and other standards bodies.
The current schema states that ALL Network Objects MUST have an identifier.
This is very strict. For example, even a network object that is never referenced MUST still have an ID. Thus the following is NOT allowed:
<nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C"> <nml:link> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/> </nml:relation> </nml:link> <nml:link> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/> </nml:relation> </nml:link> </nml:bidirectional>
Instead, everything MUST be named, like so:
<nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C"> <nml:link id="urn:ogf:network:es.net:link_A_to_C"> <!-- ADDED id --> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/> </nml:relation> </nml:link> <nml:link id="urn:ogf:network:es.net:link_C_to_A"> <!-- ADDED id --> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/> <nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/> </nml:relation> </nml:link> </nml:bidirectional>
Question 4. MUST all object have an id? a) All Network Objects MUST have an identifier. a) All Network Objects SHOULD have an identifier.
"SHOULD" means that an identifier may be left out, but only if it is clear what the consequences are (in this case: the result can not be referred to.)
As a parallel to the perfSONAR/NMC world - all first order objects have an ID field (e.g. data, metadata, subject, parameters, key). Some do not (eventType, 'parameter' [lives inside of parmeters], datum, time formats). I do not have a strong opinion on this, but I think that if you plan on ever referencing an object (e.g. in your 2nd example above creating the serial compund A_C out of A_B and B_C) it should have an ID. If the relationship is temporal and will never be referenced it won't need the ID, but it doesn't seem like a stretch to just give it one anyway. I suppose I would prefer a) to be safe, but won't defend it to the death.
The current schema states that the Syntax of the identifier MUST follow the urn:ogf:network syntax.
This might make future compatibility harder (e.g. when trying to combine it with other protocols; I can imagine that in the future other naming schema's may be developed).
Question 5. MUST urn:ogf:network syntax be used? a) All identifiers MUST follow the urn:ogf:network syntax b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network syntax c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network syntax (some more variants are possible)
No strong preference. I think that using the urn syntax helps to guarantee uniqueness, but I would need to see examples of when it would be impossible to assign this type of ID to a given object. -jason
Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref
Jeroen van der Ham:
I thought we decided on B?
Jason Zurawski:
I think b) makes the most sense; we do this in NM/NMC now.
Freek Dijkstra:
No big prefence. In order: a, c, or b
Talking in private to Jeroen (today) and Jason (at OGF), my question seems ambigious. Let me try again. Let's assume we will make a derived Ethernet schema, http://schemas.ogf.org/nml/ethernet/2015/05/ 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 OGF namespace (created for just these attribs) e) about and resource in RDF namespace Am I correct that our preferences is: Jeroen: b Jason: c Freek: a, d or e
To me it seems very weird to reuse NM-WG namespace for something trivial as this and for that reason almost ridiculous to create a dedicated namespace for that.
At the risk of making flamebait: Redefining the same thing over and over and over again (option c), seem to nullify the use of namespaces. For one thing, the power of XML or RDF comes from using libraries that understand some part of the XML, for example about ordering, namespaces, and identifiers. (To me that was the compelling reason to like RDF; the semantic stuff is only a side-effect for me). By defining this once, it is easy to augment a library to treat this as special. If we decided to redefine this over and over again, each time in a new namespace, the implementor must write the same code again and again (especially if a good XML library is used, where equal name in different namespaces are considered something different). I dislike that.
It is uncommon to see [namespace prefixes for attributes]:
<ns:element ns2:attribute="something" />
But it is possible.
Yes, it is indeed uncommon for XML. It is common for RDF/XML.
Question 5. MUST urn:ogf:network syntax be used? a) All identifiers MUST follow the urn:ogf:network syntax b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network syntax c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network syntax (some more variants are possible)
No strong preference. I think that using the urn syntax helps to guarantee uniqueness, but I would need to see examples of when it would be impossible to assign this type of ID to a given object.
I think it is always possible to assign a urn:ogf ID. The question if we allow other unique identifiers that have already be defined for other protocols. Regards, Freek
Freek/All; On 11/8/10 10:45 AM, Freek Dijkstra wrote:
Question 2. What attributes to use for references in XML? a) existing id and idref in NM-WG namespace b) redefine id and idref in NML namespace c) create dedicated namespace for just id and idref
Jeroen van der Ham:
I thought we decided on B?
Jason Zurawski:
I think b) makes the most sense; we do this in NM/NMC now.
Freek Dijkstra:
No big prefence. In order: a, c, or b
Talking in private to Jeroen (today) and Jason (at OGF), my question seems ambigious. Let me try again.
Let's assume we will make a derived Ethernet schema, http://schemas.ogf.org/nml/ethernet/2015/05/
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 OGF namespace (created for just these attribs) e) about and resource in RDF namespace
Am I correct that our preferences is: Jeroen: b Jason: c Freek: a, d or e
To me it seems very weird to reuse NM-WG namespace for something trivial as this and for that reason almost ridiculous to create a dedicated namespace for that.
At the risk of making flamebait:
Redefining the same thing over and over and over again (option c), seem to nullify the use of namespaces.
For one thing, the power of XML or RDF comes from using libraries that understand some part of the XML, for example about ordering, namespaces, and identifiers. (To me that was the compelling reason to like RDF; the semantic stuff is only a side-effect for me). By defining this once, it is easy to augment a library to treat this as special. If we decided to redefine this over and over again, each time in a new namespace, the implementor must write the same code again and again (especially if a good XML library is used, where equal name in different namespaces are considered something different). I dislike that.
It is uncommon to see [namespace prefixes for attributes]:
<ns:element ns2:attribute="something" />
But it is possible.
Yes, it is indeed uncommon for XML. It is common for RDF/XML.
If it matters that much for your use cases and you can't rationalize not re-using attribute definitions, do what you think make sense. As denoted in my first response, attributes are almost always associated with the element because there is never a need to see them re-used or sourced from alternate namesapces. Remember that we are just talking about a simple name and value pair (string datatype, nothing complex). The semantic meaning behind id and idRef would remain the same no matter what namespace you are referring to. I doubt there would ever be a case where an NML-base idRef pointing to an Ethernet id would be treated any differently than other id/idRef situations. If you forsee the relationship between ids and refs of different namespaces being meaningful, please give some examples. The added complexity to simply reuse the following text:
Identifier = attribute id { xsd:string }
IdReference = attribute idRef { xsd:string }
Hardly seems worth the trouble. -jason
Jason Zurawski wrote:
Question 3. What characters are allowed in <opaque string>? a) GLIF: A-Z a-z 0-9 - . b) unreserved: A-Z a-z 0-9 - . _ ~ c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * '& %hex
I believe we should use the approach that is going to be supported the most widely, in parsing tools/libraries and what is most closely matched to GLIF and other standards bodies.
That's the issue. :( - c or d is most widely supported in libraries. - a is most closely matched to GLIF recommendation. - b plus the ":" character is mostly used in practice My current feeling is that it is easiest to require: - The URN MAY use the characters of c or d (no further restrictions) - For lexical equivalance the URN MUST be case normalized - Other normalization MUST NOT be used (in particular, %-encoding MUST NOT be expanded) - For display purposes, the %-encoding MAY be expanded - If %-encoding is used, the OCTETS SHOULD represent UTF-8 data in NFC form. (Rationale: (1) no other restrictions beside what is already in URN; (2) easy comparison - only case conversion; (3) still possible to display non-ascii characters.)
Question 4. MUST all object have an id? a) All Network Objects MUST have an identifier. b) All Network Objects SHOULD have an identifier.
[...]
I suppose I would prefer a) to be safe, but won't defend it to the death.
You convinced me. I'll change my vote from b to a :) Freek
participants (3)
-
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham