[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Leigh Dodds" <ldodds@ingenta.com>
To: "Nicolas Lehuen" <nicolas.lehuen@ubicco.com>; <xml-dev@lists.xml.org>;
"Joe English" <jenglish@flightlab.com>
Sent: Saturday, January 19, 2002 12:08 PM
Subject: RE: [xml-dev] The task to be solved by RDDL. Re: [xml-dev] RDDL
(was RE: [xml-dev] Negotiate Out The Noise)
>
>
> > -----Original Message-----
> > From: Nicolas Lehuen [mailto:nicolas.lehuen@ubicco.com]
> > Sent: 19 January 2002 09:58
> > To: xml-dev@lists.xml.org; Joe English
> > Subject: Re: [xml-dev] The task to be solved by RDDL. Re: [xml-dev] RDDL
> > (was RE: [xml-dev] Negotiate Out The Noise)
> >
> [...]
> > -- 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 ?
>
> Lets separate these. Firstly I don't see a big problem in having large
numbers
> of roles (natures). There will be as many of these as there are types of
resource
> to associate. Purposes are more subtle as they relate to how a resource is
> going to be used, but again I'm not sure I see a 'scalability' problem.
(And I
> have read the thread).
The scalability problem is on the reader's brain side. Having a long list of
resources in an enormous RDDL document is not very useful. The only really
distinctive point about RDDL compared to other ideas is the fact that the
document I obtain is readable by a human. But if it's too big or not
structured enough or looking too much like a W3C TR (JOKE here :), nobody
will read it.
> As far as internationalisation (I18N) goes, let's look at this from a
different
> angle. For a given (X)HTML web page, how do you present alternate language
versions
> of it? Generally, you provide links to the other pages. You can do this
with
> RDDL. These alternate versions can be resources in their own right, and
may
> be simple XHTML documentation (no resources).
Yeah, let's get all human-readable resources out of the root RDDL document.
Why is it in the root RDDL document, anyway, whereas the DTDs, schemas,
stylesheets and other related resources aren't ? Just because it is supposed
to be fun to be able to type the namespace URL and read something about it.
Like many others, I don't think this is a sufficient justification.
> > -- mixing resource directory information with human readable data , thus
> > causing problems of maintenance, especially in an international context.
>
> As RDDL sets out to mix human and machine processable data, this is
> the same as saying "we need 2 separate mechanisms".
Yeah, that's what I'm telling from the start of the thread. WE NEED 2
SEPARATE MECHANISMS :
1. a way to link documents or namespaces to a meta-data directory. RDDL
assume that the link is done by resolving the namespaces URLs, that's not
enough as it forgets a lot of non-URL namespace names and we need this kind
of mechanism for documents, too, not only namespaces.
2. a way to describe associations between resources depending on their
purpose, nature, language etc. RDDL has a nice system for this (very near to
RDF), unfortunatley it screws everything by promoting the human-readable
resources and embedding it inside the resource descriptors.
The human-readable documentation should really come separately and be linked
like any other resource (schema, etc.), not embedded inside the resource
list. A first step, if you really want to keep RDDL's semantics, would be to
take out all human-readable text in separate files, define a purpose of
"human-readable documentation", and different natures for English, French,
German, Swahili, etc. Or maybe the nature of such a resource would be XHTML
and we would have to add the support for xml:lang in resource descriptors.
> > -- 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).
>
> What you're describing here sounds like what has previously been
> called 'packaging'. i.e. providing a means to identify the required
resources to
> process a document, and possibly bundle those resources with the document.
>
> Packaging isn't the problem RDDL sets out to solve, *but* it could be
> used in a packaging context. A DZIP file could contain a RDDL document.
Packaging is, well, packaging. We have two problems to answer :
- how can I obtain meta-data about a document, for example to find an
associated schema ?
- once I know there is an associated schema, where do I get it ?
Packaging is only an answer to the second question.
For the moment, if I want to associate an XML document with a default
stylesheet (bad idea, but good for my example), a DTD, an XML Schema and a
RELAX NG schema, here is what I have to write :
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE foobar PUBLIC "-//foo//bar//foobar"
"http://www.foobar.com/foobar.dtd";!>
<?xml-stylesheet href="foobar.css" type="text/css"?>
<foobar xmlns="http://www.foobar.com/namespace";
xmlns:xsi="http://www.w3.org/2001/XMLSchema";
xsi:schemaLocation="http://www.foobar.com/foobar.xsd";>
<!-- here begins the real data -->
</foobar>
... and I could not associate a RELAX NG schema, because the RELAX NG people
were sensible enough to reckon that adding a new set of PIs or specific
attributes would burden the data files even more.
What I am dreaming of, is not to go to http://www.foobar.com/namespace and
find a RDDL document. I explained in length why it is a bad idea. What I am
dreaming of, is being able to write something like :
<?xml version="1.0" encoding="iso-8859-1"?>
<?meta-data-catalog href="http://www.foobar.com/foobar.meta";?>
<foobar xmlns="http://www.foobar.com/namespace";>
<!-- real data here -->
</foobar>
And all DTDs, schemas, stylesheets, Java code, human-readable documentation
etc. being accessible through the catalog at
http://www.foobar.com/foobar.meta . If you want, a DZIP archive of schemas
could be one of the resources accessible through the catalog. But packaging
with DZIP is an orthogonal problem.
> > -- 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.
>
> I'll comment on this is a separate message. There are some issues here
that
> have nothing to do with RDDL, but how we write and apply schemas. It's
> discussing separately, IMO.
I agree. I am trying to write a small text about it, and I will put on my
website ASAP. You can have a preview here :
http://nicolas.lehuen.com/Articles/Programming/Ideas/fog0000000033.html
> > -- 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
>
> Perhaps this should be made clearer. Jonathan?
>
> > , 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.
>
> Which uses cases are non implementable? If you mean providing a packaging
> solution, or doctype replacement then these aren't RDDL use cases anyway.
There are many, but the most startling use case which is not implementable
is : how do I use RDDL to get the RDDL document for RDDL ? That is to say,
how am I supposed to use RDDL as the definite resource directory when my
document contains a mix of namespaces ?
Any claim of using RDDL to obtain schema information is a joke, because it
assumes that a document has namespace which has a schema ! This is a total
mess in concepts !
I really don't understand why you smart people don't see that this point is
a problem. It's really simple to break it ! And once again, you just didn't
gave me the algorithm I was asking for. Try to think about it, you'll see
that RDDL is really flawed.
> > -- 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.
>
> If one takes the general approach of resolving URIs via a catalog, then
any
> NS URI can be resolved to a RDDL document (either locally or remotely,
from
> the file system, or via a URL). So non HTTP URIs can be used.
Hence the need to backup the RDDL spec with the XML Catalog spec. This could
be a good beginning for the building of a truly useful RDDL.
> So generally, if a URI can be resolved to a resource, or be made to
resolve
> it a resource, then that resource can be a RDDL document.
Yeah. The interesting point is that we could drop the case about resolving
namespace URIs to find a meta-data directory and interesting ourselves to
the more general case of providing meta-data directories for document types
instead.
Regards,
Nicolas
> I could use a mailto: URI and have an auto-responder set up to mail you
> back the RDDL document if I wanted to.
>
> Cheers,
>
> L.
|
