OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] The task to be solved by RDDL. Re: [xml-dev] RDDL (was RE:

[ Lists Home | Date Index | Thread Index ]

> -----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).

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.




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS