[
Lists Home |
Date Index |
Thread Index
]
Please, please, re-read the full thread (I know, that's a lot of reading to
do). We already have described some issues about RDDl. Let me try to sum up
some of these issues here :
-- scalability : what if the number of commonly used roles is increasing to,
say, 50 ? What if you want to translate the human-readable parts in other
languages ?
-- mixing resource directory information with human readable data , thus
causing problems of maintenance, especially in an international context.
-- namespace-centricity, limiting RDDL to describing namespace meta-data,
whereas what we really need is to describe document meta-data (think of a
DOCTYPE declaration but not limited to DTDs).
-- a dangerous corollar of this namespace centricity is that people keep on
associating schemas with namespaces. This just encourages people to have a
twisted conception of namespaces.
While there are many namespaces that, right or wrong, can stand alone in
documents, and thus have associated schemas, there are schemas that define
document with a namespace mix. Those schema don't have a particularly
associated namespace, so they can't appear in a RDDL document.
And I'm not talking about exotic, rare and proprietary schemas. To begin
with, some examples are all XHTML documents that have modules in other
namespaces, like RDDL and WAP 2.0. There are DTDs and schemas for those
language, but RDDL is not fit to handle them.
- As an illustration of the previous issue, it is rather funny to think that
RDDL itself is out of its own scope. Granted, the RDDL documentation is an
RDDL document. But like I wrote before, you cannot use the RDDL resolution
mechanism to go to http://www.rddl.org/RDDL from a RDDL document.
Show me the algorithm. I have asked for it twice, but nobody answered. I'm
not asking for heuristics (like "I have a look at the namespace
declarations, see those XHTML, RDDL and XLink namespace names, and decide to
go for the RDDL one") or science-fiction ("I fetch all RDDL documents from
each and every namespace name I find, and merge them together"). I want an
algorithm that can be easily implemented today, if the fate of RDDL is to be
used today.
And once you've shown me the algorithm, show me the same algorithm for
XHTML+SVG, WAP 2.0, and my proprietary schema that mix namespaces. Hint :
the algorithm has to be exactly the same.
-- describing document meta-data may not be the intended purpose of RDDL,
its author may purposely have restricted their scope to describing
namespaces meta-data. But in that case, this has to be written clearly
somewhere in the RDDL documentation, and a lot of use cases for RDDL should
be marked as non implementable. There are people casting silver bullets from
RDDL, which is the main reason why this thread is so big.
-- even in the namespace meta-data description domain, RDDL is not complete.
For now, it only works for resolvable namespaces names, e.g. URLs. This
leaves non-URL namespaces names aside, making them the ugly duck because
they can't participate to the RDDL frenesy. Should RDDL be successfull, this
would create a de facto assumption that namespace names = URL, because
nobody would want to be left aside. The problem is that namespace names !=
URL. One should always remember that a namespace name is just half of a
QName, that's the only assumption that we should make. Changing the
namespace names spec and forcing them to be resolvable URLs could be done,
but we have to think twice about it before, as it has big consequences both
on the semantic level (a namespace name would be no more the left half of a
QName) and on the infrastructure level.
The RDDL buzz should really, really calm down, because otherwise it will do
lots of harm to the fragile architecture of XML, namespaces and schemas. You
should reckon that RDDL began by a riddle and found itself pushed in front
of the scene without having the sufficient background to deserve the hype
and buzz it generates. Just have a look at all the holes the spec has, and
all the orphans documents, schemas and namespaces it would create. This is
not meant to be agressive towards RDDL authors ; I'm sure they do understand
this too. We all should work together at designing a system that scavenge
the good ideas of RDDL but try to solve the problems mentioned above.
Best regards,
Nicolas
----- Original Message -----
From: "Joe English" <jenglish@flightlab.com>
To: <xml-dev@lists.xml.org>
Sent: Saturday, January 19, 2002 6:18 AM
Subject: Re: [xml-dev] The task to be solved by RDDL. Re: [xml-dev] RDDL
(was RE: [xml-dev] Negotiate Out The Noise)
>
> Dare Obasanjo wrote:
>
> > ISSUE 1: Namespace URIs should not be HTTP URLs and where possible this
shoul
> > be deprecated. [...]
>
> > ISSUE 2: There should be a way to discover information about a Namespace
URI
> > in both human readable and machine comprehendable form. [...]
> > I'd like to _at_the_very_least_ be
> > able to a.) discover the semantics of the elements and attributes in the
> > document by looking up the namespace URI and locating a human readable
> > document and b.) obtain validation information for the namespace (e.g.
the
> > XSLT schema or DTD for the XSLT namespace) IF the creator of the
namespace
> > (right phrase?) has deigned to make such information available.
>
> RDDL is designed to solve *exactly* issue (2).
> However it can only really work reliably if the namespace
> creator uses a resolvable URI (i.e., http://*) to identify it,
> contrary to issue 1.
>
> > From where I
> > sit, RDDL does not give me this although RDDL is the "Worse is better"
> > solution.
>
> RDDL gives you exactly this: a human-readable XHTML document
> with computer-readable links to computer-processable information
> (schemas, stylesheets, etc.) relevant to the namespace.
>
> What's missing from where you sit? Is it issue 1 (don't use
> HTTP URIs for namespace names)?
>
>
> --Joe English
>
> jenglish@flightlab.com
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
