Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Leigh Dodds" <ldodds@i...> To: "Nicolas Lehuen" <nicolas.lehuen@u...>; <xml-dev@l...>; "Joe English" <jenglish@f...> Sent: Saturday, January 19, 2002 12:08 PM Subject: RE: The task to be solved by RDDL. Re: RDDL (was RE: Negotiate Out The Noise) > > > > -----Original Message----- > > From: Nicolas Lehuen [mailto:nicolas.lehuen@u...] > > Sent: 19 January 2002 09:58 > > To: xml-dev@l...; Joe English > > Subject: Re: The task to be solved by RDDL. Re: RDDL > > (was RE: 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.
|
