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


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]

----- Original Message ----- 
From: "Tim Bray" <tbray@textuality.com>

> Heavens, I think Paul has single-handedly shattered the 
> record for volume & intensity of flameage over a spec
> relative to the volume of the spec itself.  Given that
> the record was previously held jointly by several 
> xml-dev contributors with respect to the Namespaces spec
> spec, this is quite an achievement.

Flaming is implied by the nature of mailing list, 
because "no, I disagree" statements are allowed 
by policy, but "yes I agree" statements are forbidden, 
because they provide no 'new' content. 

Also, I think that  'RDDL' is not such a subtile thing 
as it may look, because the namespaces are 
in the very core of XML, so playing with these 
entities affects the entire building.

> >Not that I have anything against 'let's be first to abuse
> >namespaces URL' ( and you *already* started the abuse
> >with hidden schema extension ) 
> ...
> >1. The Process RDDL is developeing. "It is just a documentation,
> >with a few URLs, no it has some proprietary hooks into schema
> >parsers already
> ?? RDDL has no linkage to or preference for any schema dialect.

According to letter from Jonathan, reffering to 
'XSV has support for RDDL that allows for 
multiple namespaces' - it already *has*  the linkage.

Nobody elaborated on that 'support'. I've provided 
my guess what that support could be and there was no 

In general, there is one core problem.

So, we can say that 'Resource-to-fetch'
is identified by :

1. Namespace ( unique URL )
2. Role. 
3. Purpose.

Note that there is no 'context' here. One may 
try emulating 'context' with 'Roles' and 'Purposes',
but that would be a logical hack again. To 
understand what I'm talking about, we better 
start discussing some particular application 
that would try building on RDDL  and mixed 
namespaces.  I tried that right from the 
beginning, with 'receipe' example asking what's 
going on when the  recipe is embedded into 
another document ( that was a goal of namespaces 
to support 'mixing' ), but nobody has answered, 
other than pointing to *XSV* hack!

What in particular happens in the situation when 
document has 2 namespaces mixed is unclear. 

> >Everywhere. Any W3C paper. Any technical solution
> >out there has some *clear* problem that it tries to
> >solve and the *problem* can be explained in simple
> >terms.
> >
> >What is the *clear* problem that RDDL is gonna solve?
> People use namespaces to identify and disambiguate
> elements and attributes.  

I'm very happy to see the healthy reaction I was 
begging for. 

> (a) How can I as a human being find out what the 
>     namespace is all about?

Read the document, published 'at the end' 
of namespace URL.

HTML document. Server, hosting 
that document,  can go down, no big deal, 
you'd  read that documentation later.

> (b) How can I go about discovering what {schemas, 
>     stylesheets, java classes, DTDs, etc etc) are
>     out there for this namespace.

Depends on the *task*  you need this information for.
If that's *educational* task, that makes it equal to (a).

There would be some URLs in the (a) documentation
and those URLs will lead you to the appropriate 
If you want to fetch those resources for a 
*processing* - the task *immediately* becomes 
*much* more complex. For example, the server 
that hosts the 'dispatcher' has to be up and running
every time, or caching steps in e t.c  another 
level of indirection is needed - picture becomes 
absolutely different. 

To implement healthy *processing* backbone for 
RDDL one should throw out the current paper and 
start from scratch.
> That's all.  Nothing complicated.

Well, it *is* complicated. We're kinda in a loop here.

Your letter positions RDDL as a 'documentation with some 
fancy links' for humans - and that is not a disaster. It is 
OK to make some 'standard view for all resources 
that are possibly related to some Namespace'. 

If *that's*  the task - why would not just use some 
'standard'  DTD / Schema / CSS ?

Just provide something like a 'Docbook  for Namespaces 
documentation'. What's wrong with that? Why do you need 
writing *any* software in this case?
And it is *absolutely* different story if it is about 
'computers' fetching something,  when *processing*
some namespace. Another set of requirments. 

How can you make something equally good 
for computers and people??? Computers are dumb 
and robust, people are 'flexible' and unreliable! 

> RDDL isn't a complete solution to all aspects of this
> problem.  It's trying to hit an 80/20 point.  Just like
> HTTP.  -Tim

If RDDL is an attempt to produce some standard to 
document Namespaces for human beings - that's consistent 
and clear ( the syntax immediately looks questionable, 
but at least the problem domain or RDDL becomes clear
and I'd gladly welcome such a healthy effort ).

Why XSV 'implements RDDL' then? Why we were 
talking about 'distributed java applications' ?

When you send a messy message - you get a messy responce.

RDDL sends a messy, self-contradicting message and 
I wish that perhaps you can make it clear to everybody, 
what is this RDDL thing *really* about?



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

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