Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----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). 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). > -- 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". > -- 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. > -- 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. > -- 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. > -- 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. 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. 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.
|
