<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc docName="draft-rsalz-qname-urn-02" ipr="pre5378Trust200902">

<front>

  <title abbrev="QNAME URN">The QName URN Namespace</title>

  <author initials="D." surname="Orchard" fullname="David Orchard">
    <organization>Ayogo Games, Inc.</organization>
    <address>
      <email>orchard@pacificspirit.com</email>
    </address>
  </author>

  <author initials="R." surname="Salz" fullname="Rich Salz">
    <organization>IBM</organization>
    <address>
      <email>rsalz@us.ibm.com</email>
    </address>
  </author>
  
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>	
      <uri>http://greenbytes.de/tech/webdav/</uri>	
    </address>
  </author>


  <date month="March" year="2010" day="7"/>

  <keyword>Namespaces</keyword>
  <keyword>QName</keyword>
  <keyword>XML</keyword>
  <keyword>URN</keyword>

  <abstract>
    <t>This specification defines a Uniform Resource Name namespace for XML
      namespace-qualified names, QNames. As long as the URN is encoded in
      the same character set as the document containing the original QName,
      the Qname URN provides enough information to maintain the semantics,
      and optionally the exact syntax, of the original name.</t>
  </abstract>

  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Please send comments to the xml-dev mailing list
      (<eref target="http://www.xml.org/xml-dev/"/>).
    </t>
    <t>
      XML versions, latest edits and the issues list for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-rsalz-qname-urn"/>.
    </t>
  </note>
</front>

<middle>













  <section anchor="introduction" title="Introduction and Motivation">
    <t>This specification defines a Uniform Resource Name namespace for XML
      namespace-qualified names, QNames. As long as the URN is encoded in
      the same character set as the document containing the original QName,
      the Qname URN provides enough information to maintain the semantics,
      and optionally the exact syntax, of the original name.</t>

    <t>There are a variety of situations when a QName may need to be mapped
      to a URI. For example, when exchanging (or referencing) an identifier
      for an XML element contained within a document, and the medium of
      exchange prefers URIs to QNames, such as an XML Schema anyURI data
      type. Another scenario is for comparing the identifiers, which can be
      simpler by comparing just a string without having to also compare the
      context setting XML namespace attribute that may be declared
      arbitrarily earlier in the document.</t>

      <t>The XML Namespaces specification <xref target="XMLNS"/> does not
        provide a canonical mapping between QNames and URIs. Any XML
        specification that wants to enable identifier exchanges must define
        a language specific QName to URI mapping. There have emerged a
        variety of different algorithms and solutions for the mapping. To
        date, there have been no standardized algorithms available that
        they can re-use, which has increased their efforts. A standardized
        mapping, such as this, should provide increased productivity.</t>

      <t>Almost all of the algorithms for Qname to URI mappings are based
        upon concatenation of the URI and the name with variations based
        upon prefix inclusion, namespace name and name separator, etc.
        These are typically problematic because it is difficult to recover
        the QName from the URI as the namespace name and name separator may
        have already been used in the namespace name. Having the namespace
        name at the end of the identifier string avoids these and other
        problems.</t>

  </section>

  <section anchor="template" title="Namespace Registration Template">
    <t>The following paragraphs contain the URN namespace registration
      data, as defined in <xref target="RFC3406"/>.</t>
      
    <t>
      Namespace ID:
      <list>
        <t>
          qname
        </t>
      </list>
    </t>  



    <t>
      
<?rfc needLines="4"?>Registration Information:
      <list>
        <t>
          Version number: 2
        </t>
        <t>
          Registration date: 2010-03-07
        </t>
      </list>
    </t>
    


    <t>
      Declared registrant of the namespace:
      <list>
        <t>Julian Reschke
              &lt;julian.reschke@greenbytes.de&gt; (see Authors' Adresses 
          Section).
        </t>
      </list>
    </t>
    
    <t>
      Declaration of syntactic structure:
      <list>
        <t>
          The QName URN is structured as four colon-separated fields.
          Note that colons within the fourth field, the URI part, are not
          significant; the entire fourth field is treated as a single
          opaque entity by this URN scheme.
        </t>
        <t>
          The first field identifies the naming scheme.
          The second contains the QName prefix, or an empty string if
          the QName comes from the default namespace, or an asterisk
          if the prefix is not significant.
        </t>

        <t>
          A QName URN is defined by the following ABNF <xref target="RFC5234"/>:
          <figure><artwork type="abnf"><![CDATA[
      qnameURN     = "qname" ":" prefix ":" localname ":" uri
      prefix       = ncname / "" / "*"
      localname    = ncname
      uri          = <any valid URI>
      ncname       = <see Production 4 of [XMLNS], Section 3>
      ]]></artwork></figure>
        </t>
        <t>
          Here are three examples of a QName URN:
          <figure><artwork type="example"><![CDATA[
      urn:qname:foo:OK:http://example.com/ws/foo.xsd
      urn:qname::OK:http://example.com/ws/foo.xsd
      urn:qname:*:Reject:http://w3.org/2002/xkms#
      ]]></artwork></figure>
          The first correspond to the following element content
          QNames (the element name is not significant):

      <figure><artwork type="example"><![CDATA[
      <foo xmlns:foo="http://example.com/ws/foo.xsd">foo:OK</foo>
      <foo xmlns="http://example.com/ws/foo.xsd">foo:OK</foo>
      ]]></artwork></figure>
          The third example would match both of the others, as
          well as an inifinite number of QNames, since
          the namespace prefix is explicitly marked as "don't-care."
        </t>
      </list>
    </t>

    <t>
      Relevant ancillary documentation:
      <list>
        <t>
          <xref target="XML"/>
          <xref target="XMLNS"/>
        </t>
      </list>
    </t>

    <t>
      
<?rfc needLines="4"?>Identifier uniqueness considerations:
      <list>
        <t>
          An XML QName is semantically defined as a (namespace-uri,
          localname) pair; the namespace prefix is not significant.
          For some applications, such as signature functions, the
          prefix is important and must be preserved.
        </t>
        <t>
          The QName URN provides both a one-to-one mapping, that
          preserves the uniquess of the underlying QName, and an
          explicit many-to-one mapping, that does not preserve
          the uniquess when it is not important to do so.
        </t>
      </list>
    </t>

    <t>
      Identifier persistence considerations:
      <list>
        <t>
          QName URN's have the same persistance as the underlying
          XML QName from which they are derived.
        </t>
      </list>
    </t>
  
    <t>
      Process of identifier assignment:
      <list>
        <t>
          Assignment of identifiers depends on the original XML QName,
          typically deferring to the namespace URI. Anyone with access to
          an XML QName can create an equivalent QName URN; no registration
          is required.
        </t>
      </list>
    </t>

    <t>
      Process for identifier resolution:
      <list>
        <t>
          Inherited from the QName resolution rules (typically the
          namespace URI) from which the QName URN is created.
        </t>
      </list>
    </t>

    <t>
      Rules for Lexical Equivalence:
      <list>
        <t>
          If necessary, convert each QName URN to the same encoding.
          The encoding of a QName URN is determined by context, and depends
          on the encoding of the document in which it appears.
        </t>
        <t>
          To be lexically equivalent the resultant QName URN's must be
          identical when compared byte-for-byte. To be semantically
          equivalent, ignore the prefix field when comparing bytes.
        </t>
      </list>
    </t>

    <t>
      Conformance with URN Syntax:
      <list>
        <t>
          Fully conformant.
        </t>
      </list>
    </t>

    <t>
      Validation mechanism:
      <list>
        <t>
          Inherited from the namespace URI of the original QName.
        </t>
      </list>
    </t>
            
    <t>
      
<?rfc needLines="4"?>Scope:
      <list>
        <t>
          Inherited from the original QName.
        </t>
      </list>
    </t>
  </section>




  <section anchor="security-considerations" title="Security Considerations">
    <t>QName URN's provide a way to transcribe XML QName's into and out of
      URN syntax. Any security considerations are inherited from the
      original QName.</t>
  </section>

</middle>

<back>

  <references title="Normative References">

    <reference anchor="XML" target="http://www.w3.org/TR/2008/REC-xml-20081126/">
      <front>
        <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
        <author initials="T." surname="Bray" fullname="Tim Bray">
          <organization>Textuality and Netscape</organization>
          <address>
            <email>tbray@textuality.com</email>
          </address>
        </author>
        <author initials="J." surname="Paoli" fullname="Jean Paoli">
          <organization>Microsoft</organization>
          <address>
            <email>jeanpa@microsoft.com</email>
          </address>
        </author>
        <author initials="C. M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
          <organization>W3C</organization>
          <address>
            <email>cmsmcq@w3.org</email>
          </address>
        </author>
        <author initials="E." surname="Maler" fullname="Eve Maler">
          <organization>Sun Microsystems, Inc.</organization>
          <address>
            <email>eve.maler@east.sun.com</email>
          </address>
        </author>
        <author initials="F." surname="Yergeau" fullname="Francois Yergeau"/>
        <date day="26" month="November" year="2008"/>
      </front>
      <seriesInfo name="W3C" value="REC-xml-20081126"/>
    </reference>

    <reference anchor="XMLNS" target="http://www.w3.org/TR/2009/REC-xml-names-20091208/">
      <front>
        <title>Namespaces in XML 1.0 (Third Edition)</title>
        <author initials="T." surname="Bray" fullname="Tim Bray">
          <organization>Textuality</organization>
          <address>
            <email>tbray@textuality.com</email>
          </address>
        </author>
        <author initials="D." surname="Hollander" fullname="Dave Hollander">
          <organization>Contivo, Inc.</organization>
          <address>
            <email>dmh@contivo.com</email>
          </address>
        </author>
        <author initials="A." surname="Layman" fullname="Andrew Layman">
          <organization>Microsoft</organization>
          <address>
            <email>andrewl@microsoft.com</email>
          </address>
        </author>
        <author initials="R." surname="Tobin" fullname="Richard Tobin">
          <organization>University of Edinburgh and Markup Technology Ltd</organization>
          <address>
            <email>richard@cogsci.ed.ac.uk</email>
          </address>
        </author>
        <author initials="H.S." surname="Henry" fullname="Henry S. Thompson">
          <organization>University of Edinburgh and W3C </organization>
          <address>
            <email>mailto:ht@w3.org</email>
          </address>
        </author>
        <date month="December" day="8" year="2009"/>
      </front>
      <seriesInfo name="W3C" value="REC-xml-names-20091208"/>
    </reference>

    <reference anchor="RFC3406">
      <front>
        <title>Uniform Resource Names (URN) Namespace Definition Mechanisms</title>
        <author initials="L." surname="Daigle" fullname="Leslie L. Daigle">
          <organization>Thinking Cat Enterprises</organization>
          <address>
            <email>leslie@thinkingcat.com</email>
          </address>
        </author>
        <author initials="D." surname="van Gulik" fullname="Dirk-Willem van Gulik">
          <organization>WebWeaving Internet Engineering</organization>
          <address>
            <email>dirkx@webweaving.org</email>
          </address>
        </author>
        <author initials="R." surname="Iannella" fullname="Renato Iannella">
          <organization>IPR Systems Pty Ltd.</organization>
          <address>
            <email>renato@iprsystems.com</email>
          </address>
        </author>
        <author initials="P." surname="Faltstrom" fullname="Patrik Faltstrom">
          <organization>Cisco Systems Inc</organization>
          <address>
            <email>paf@cisco.com</email>
          </address>
        </author>
        <date year="2002" month="October"/>
      </front>
      <seriesInfo name="BCP" value="33"/>
      <seriesInfo name="RFC" value="3406"/>
    </reference>

    <reference anchor="RFC5234">
      <front>
        <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
        <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
          <organization>Brandenburg InternetWorking</organization>
          <address>
            <email>dcrocker@bbiw.net</email>
          </address>  
        </author>
        <author initials="P." surname="Overell" fullname="Paul Overell">
          <organization>THUS plc.</organization>
          <address>
            <email>paul.overell@thus.net</email>
          </address>
        </author>
        <date month="January" year="2008"/>
      </front>
      <seriesInfo name="STD" value="68"/>
      <seriesInfo name="RFC" value="5234"/>
    </reference>

  </references>

<section title="Change Log (to be removed by RFC Editor before publication)">

<section title="Since draft-rsalz-qname-urn-00">
<t>
  Updated references and fix reference to XMLNS which was meant to reference XMLNS11.
  Add a set of issues:
  "any-uri",
  "contacts",
  "curie",
  "examples",
  "i18n",
  "mailing-list",
  "qname-vs-expname",
  "reg-info",
  "registrant",
  "xml11".
</t>
</section>


<section title="Since draft-rsalz-qname-urn-01">
<t>
  Close issues "contacts" and
  "mailing-list"
  as resolved (already in -01).
  Close issues "registrant" and
  "xml11".
  Update registration info ("reg-info").
</t>
</section>


</section>

<section title="Resolved issues (to be removed by RFC Editor before publication)"><t>
          Issues that were either rejected or resolved in this version of this
          document.
        </t><section title="contacts"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Update author information.
  </t><t>Resolution (2010-03-07): 
    Done in -01.
  </t></section><section title="mailing-list"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-12): 
    In the boilerplate, state where this Internet Draft should be discussed.
    Proposal: xml-dev.
  </t><t>Resolution (2010-03-07): 
    Done in -01.
  </t></section><section title="registrant"><t>
        In Section 2:
      </t><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Update registrant info.
  </t><t>Resolution (2010-03-07): 
    Make the editor the registrant.
  </t></section><section title="xml11"><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Consider removing any material related to XML 1.1.
  </t><t>Resolution (2010-03-07): 
    Done.
  </t></section></section><section title="Open issues (to be removed by RFC Editor prior to publication)"><section title="edit"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2010-03-07): 
    Umbrella issue for editorial changes.
  </t></section><section title="curie"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-12): 
    Maybe we should clarify the relation with CURIEs (which can be confused with
    QNames)?
  </t></section><section title="qname-vs-expname"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-12): 
    There's a risk that we confuse people by claiming this is about QNames.
    What we map to URNs is the triple (namespace-name, local-name, prefix),
    where the prefix is optional. The tuple (namespace-name, local-name)
    is the *expanded name*, not the QName. Options: (1) just clarify the
    prose, (2) rename the URN scheme (is it in use already?) to something
    like "xmlname".
  </t></section><section title="i18n"><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Need to state how non-ASCII characters are mapped to the URN.
  </t></section><section title="reg-info"><t>
        In Section 2:
      </t><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Update registration info.
  </t></section><section title="any-uri"><t>
        In Section 2:
      </t><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2009-12-12): 
    Need a grammar for "any valid URI". Do we follow stricly XMLNS,
    which would make it a "URI reference" as per RFC 3986, or do we tolerate
    junk and/or IRIs (no offense). Also, we need to state that this 
    part of the URN will be empty for elements that are in no namespace
    (right?).
  </t><t>julian.reschke@greenbytes.de (2010-03-07): 
    In particular: how do we treat namespace names that use a fragment
    identifier? We can't allow the "#" character in the URN (by definition).
  </t></section><section title="examples"><t>
        In Section 2:
      </t><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2009-12-11): 
    Having just examples of QNames in element content might be confusing
    to people not familiar with that use case; we also should have at least
    one example for an XML element name, and for a QName in content.
    (potentially also move the examples out of the registration template?)
  </t></section></section></back>

</rfc>