[
Lists Home |
Date Index |
Thread Index
]
There are two issues I see here. One with which I agree with you completely
and another that I think needs to be addressed in more general a manner than
RDDL currently does and which I am curious as to your opinions on.
ISSUE 1: Namespace URIs should not be HTTP URLs and where possible this should
be deprecated. Namespaces are meant as a means to namespaces to identify and
disambiguate elements and attributes. Confusing the issue by tying these
namespaces to a web resource is incorrect because it confuses their nature and
builds certain expectations in people. Here I agree with you.
ISSUE 2: There should be a way to discover information about a Namespace URI
in both human readable and machine comprehendable form. Regardless of whether
the namespace URI is "urn:schemas-microsoft-com:datatypes" or
"http://www.w3.org/1999/XSL/Transform";, I'd like to _at_the_very_least_ be
able to a.) discover the semantics of the elements and attributes in the
document by looking up the namespace URI and locating a human readable
document and b.) obtain validation information for the namespace (e.g. the
XSLT schema or DTD for the XSLT namespace) IF the creator of the namespace
(right phrase?) has deigned to make such information available. From where I
sit, RDDL does not give me this although RDDL is the "Worse is better"
solution.
So is the expectation in ISSUE 2 reasonable or should we continue with the
message that
namespaceURI == HTTP URL that may or may not contain
human or machine readable information.
I hope the answer to the above question is NO and we can eventually work out a
scheme that provides the basic needs raised in ISSUE 2 above without adding an
excessive complexity burden on users, authors of XMl documents or parser
implementors.
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #49
If I learn the whereabouts of the one artifact which can destroy me, I
will not send all my troops out to seize it. Instead I will send them
out to seize something else and quietly put a Want-Ad in the local paper.
----- Original Message -----
From: "Paul T" <pault12@pacbell.net>
To: "Tim Bray" <tbray@textuality.com>; "Jonathan Borden"
<jborden@mediaone.net>; <xml-dev@lists.xml.org>
Sent: Friday, January 18, 2002 4:56 PM
Subject: [xml-dev] The task to be solved by RDDL. Re: [xml-dev] RDDL (was RE:
[xml-dev] Negotiate Out The Noise)
>
> ----- 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.
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
