[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How could RDDL be distributed ?
- From: Eric van der Vlist <vdv@dyomedea.com>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Tue, 16 Jan 2001 12:00:54 +0100
Hi,
<disclaimer>
My jumping that late in the wagon shouldn't be seen as a lack of
interest and RDDL is one of the 2 coolest ideas I have heard for months
(the other one being TREX)...
</disclaimer>
I wonder though if RDDL is addressing all the issues we had with DTDs
and DOCTYPE.
Going back to our roots, SGML and XML have felt the need to separate the
formal identifier of the document type from the location of the DTD and
I think there is still this need with namespaces and that one should be
able to separate the location of the RDDL document from the namespace
that is the "name" of a vocabulary.
We can probably learn from recent experiences to give a hint on how this
could be achieved and I'd suggest that we give the possibility to define
alternative locations at the 3 places where it seems possible to do so
(by order of precedence):
1) Like it's specified by W3C XML Schema, and like it's the case with
XSLT, the APIs should allow to define alternative locations for the RDDL
documents.
This functionality is lacking in XML 1.0 and the workarounds (hacking an
entity resolver or defining bunch of symbolic links) aren't really
satisfactory.
2) Still like it's the case for W3C XML Schema or XSLT, it should be
possible to define alternative locations in the instance documents.
This would probably lead to defining a namespace for RDDL in instance
documents.
3) It should be possible to define alternate locations in the RDDL
documents themselves.
These mirrors locations and the hints to let applications know how/when
they should use the mirrors might be defined as RDDL resources...
The next thing if we'd want to go in this direction would probably be to
facilitate the management of the replication of RDDL documents.
Things such as a version id and a time to live borrowed from DNS systems
could be of use.
Another alternative would be to rely exclusively on the protocol caching
facilities, but I think that they are currently used in a too randomly
fashion to be considered as reliable.
These are just first thoughts about this issue that --unless I have
missed some exchanges-- doesn't seem to have surfaced yet.
Hope this helps
Eric
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.com
http://xmlfr.org http://4xt.org http://ducotede.com
------------------------------------------------------------------------