[
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
answer.
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.
Still.
> >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
resources.
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?
Rgds.Paul.
|
