[Nml-wg] Identifiers

Freek Dijkstra Freek.Dijkstra at sara.nl
Sun Nov 7 13:16:08 CST 2010


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/docman.root.meeting_materials.ogf30/doc16105):

> 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


More information about the nml-wg mailing list