OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Impact of the usage of unique identifier as URN intoXML do

[ Lists Home | Date Index | Thread Index ]

On Mon, 2004-03-15 at 11:51, Hess Yvan wrote:
> In the context of our applications, we have choose to use URN as the
> standard form of our generated documents identifier. Here is an example:
> <document id="urn:hsc:EFECD0FF-C0A8021C08DEE071-D030940E">
>   <blabla></blabla>
> </document>
> This form is not compatible with ID/IDREF type provided by XML schema but is
> compatible with key/keyref mechanism. In the context of our schema we
> defined it as follow:
> <xs:key name="DocIdentifier">
>   <xs:selector xpath="."/> 
>   <xs:field xpath="@id"/>
> </xs:key>
> It works fine, but I don't know the future impacts/limitation of such
> choice, specially concerning the usage of URN as unique identifier in
> conjunction with others XML technologies. Does anybody have any comments,
> suggestions or best practices about this subject? Can you see future
> limitation?

I do not think URNs would limit you more than any other identification
scheme, and considerably less than some.

With URNs you need to provide your own lookup mechanism, of course. for
example, if you want to reference a document from an HTML document
displayed in a web browser you can't write

<a href="urn:hsc:EFECD0FF-C0A8021C08DEE071-D030940E">My Document</a>

because the browser won't know how to resolve the URN into a URL.
However, you could do this:

href="http://www.imtf.com/urnlookup?urn:hsc:EFECD0FF-C0A8021C08DEE071-D030940E";>My Document</a>

Your source documents can of course contain some other linking scheme:

<doclink xlink:href="urn:hsc:EFECD0FF-C0A8021C08DEE071-D030940E"
xlink:title="My Document"/>

Transforming the "doclink" element to an "a" element can be done with
XSLT, a DOM transformation, SAX, or whatever XML transformation
tool/technology you prefer.

The limitations you may come across will probably not be inherent in
URNs per sť. Rather, they will be inherent in how you choose to
implement them.

For example, the URN scheme in your example does identify a document,
but it does not say anything about versioning, revision status,
language, or other things that may be of interest. (Or not, depending on
your situation).

You have also chosen to include the URN identifying the document in the
document itself. This may be good, or bad, again depending on the
circumstances. For example, if someone creates a new version of the
document, or a translation, the URN must be updated. Unless your
authoring/translation system updates the URN, the new document may be
stored with the old URN, and chaos may ensue. (I have seen that happen,
though with other kinds of identifiers than URNs.)

Another thing is that while you are certainly free to call the attribute
where you store the document identifier whatever you want, the name "id"
is strongly associated with ID type fragment identifiers. Your use is
different. This is may cause confusion at some point, especially if you
also use the "id" attribute to identify fragments inside a resource that
is identified by a URN. (If you don't have cross references and other
hyperlinks that target document fragments now, chances are that you will
in the future.)



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS