A sane document management approach:
I manage my documents with a key, composed with some fields of my XML
documents.
When I have to refer to documents, I use a canonical form of the key so
that I can use classical links such as <a href="...">
This canonical form is naturally an URN
The problem when using URN, is that the sub-scheme must be registered,
otherwise collisions may happen if somebody else decide to use the same
name, exactly like with XML elements; a solution is to use a namespace
URI instead, because namespace URIs can stand for universal IDs. People
at W3C already invent the thing, why not extending it for other purpose ?
The XML URN Scheme (XUS) is based on this : the sub-scheme is indirectly
a universal ID
<a href="urn:xus:..."
xmlns:xus="http://www.inria.fr/xml/xus/xml-urn-scheme">
This ID just denotes that sub-sub-schemes are using xmlns declarations
for the next scheme (called the delegate scheme); then a sub-sub-scheme
can universally (thanks to a namespace URI, not a collisionnable string)
rules the scheme specific part remaining.
<a href="urn:xus:my:fields"
xmlns:xus="http://www.inria.fr/xml/xus/xml-urn-scheme"
xmlns:my="http://www.foo.org/my-scheme">
A XUS scheme for document management:
The scheme for the XUS application defined below is
http://www.inria.fr/xml/xus/dms-xus-scheme
Here are some expectations that Document Management Systems may cover:
-documents are stored in a database
-a set of related documents are grouped in collections often structured
hierarchically
-a document is composite, that is to say composed of several "files":
texts and resources such as images, videos, etc
-a document is managed in "variants", such as the language, the version,
or both
-a document may have meta-datas, views (for example a PDF view)
-etc
Considering a document, what is needed is an identifier that indicates
which database is storing it and which field structure it follows. Once
again, let's use a namespace URI.
For example, http://www.foo.org/my-dms denotes that the fields used are
a reference and a version (the variant); notice that this ns URI doesn't
indicate where is located the database; it's just an ID that indicates
at most the owner of the database, and that applications may use.
The DXS (DMS XUS Scheme) components are:
-the collection path
-the reference
-the version
-the optional resource path
-the optional fragment
Formally, the syntax of a DMS XUS URI is the following :
urn:xus-prefix:dms-prefix:(dms-base[:/dms-collection-path]):(dms-field[:dms-field])[:resource-path][#fragment]
where square brackets [...] delineate optional components and the
characters :, (, ) and # stand for themselves and
* urn is a string that stands for itslef and denotes that the URI
is an URN
* xus-prefix is a prefix bound to the XUS namespace URI :
http://www.inria.fr/xml/xus/xml-urn-scheme. The usual prefix is xus, but
any other prefix bound to the XUS namespace URI suits.
* dms-prefix is a prefix bound to the DMS XUS namespace URI :
http://www.inria.fr/xml/xus/dms-xus-scheme. The usual prefix is dxs, but
any other prefix bound to the DMS XUS namespace URI suits.
* dms-base the prefix of the DMS XUS part scheme bound to a
namespace URI.
* dms-collection-path is a path to the collection in the base ;
each element of the path is a qualified name, and is separated with the
slash / character
* dms-field is a field that identifies a document
* resource-path is a path to a resource of the document
* fragment is an XPointer that delineates a fragment of the resource
Example:
<a href="urn:xus:dxs:(my-base:/family):(myWife:2.0)"
xmlns:xus="http://www.inria.fr/xml/xus/xml-urn-scheme"
xmlns:dxs="http://www.inria.fr/xml/xus/dms-xus-scheme"
xmlns:my-base="http://www.foo.org/my-dms">
Other valid URNs:
urn:xus:dxs:(my-base:/family):(myWife:2.0)#vitalStatistics
urn:xus:dxs:(my-base:/family):(myWife:2.0):img/photo.jpg
urn:xus:dxs:(my-base:/family):(myWife)
The last URN shows the document referenced without its variant; the
behaviour may vary according to the application, that may rely on the
semantic of the attribute used or its host element; for example, it may
draw up the list of all versions of the document, or build a link to the
last document, or the last that has been validated if this feature is
relevant, or any other useful thing if other variants are used.
What to do with URNs ?
URNs are very efficient because even when things are moving on the Web,
URNs don't change; URNs are the best support for document
identification. But if URNs are found in source documents, they must be
processed in at least 2 different ways :
-a publishing application must know how to retrieve the resources stored
in a database it can access
-it must also know how to convert URN to URL so that links are
understandable by your favorite browser.
Problems arise with sharability: when 2 companies are exchanging
documents, they may not share the bases, the schemes, and the publishing
processes; in this case, the exchanging process should be done after URN
conversion.
Testimonial:
I experienced myself XUS with DXS in a very simple manner : my DMS is
just a file system where a simple mapping allows to retrieve the
documents; similarly, a target web view maps the documents to
traditional URLs
I also plan to move my XML documents to an XML native database with fiew
DMS features
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
