[
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.
Cheers,
L.
|
