[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Resource Gloss (Human Readable)
- From: Jonathan Borden <firstname.lastname@example.org>
- To: Rick Jelliffe <email@example.com>, firstname.lastname@example.org
- Date: Wed, 03 Jan 2001 22:19:19 -0500
Rick Jelliffe wrote:
> From: Jonathan Borden <email@example.com>
> > It does turn out that this does provide a solution for the otherwise
> > contensious and nasty problem of what a namespace URI ought resolve to.
> No. it does not, because the same kind of idea has been mooted time and
> again and it is not what a large group of users and developers expect or
> want, unfortunately.
Note that I term
1) RDDL provides *a* solution to the contensious problem, namely:
2) What ought a namespace URI resolve to?
(this is different than saying that a namespace URI *ought* resolve to a
> ... I completely disagree that there should be any
> expectation of human-readable documentation an http: Namespace URI ref.
Generally when a user types a URL into a browser there is the
expectation that something which makes sense will appear. At a minimum a
user who requests text should get text.
Of course XML names does not require a namespace URI be resolvable at
all, so according to REC-xml-names you are correct. However when a URI is
resolvable there should be at least some form of human readable
documentation, though there may be more.
> What should be retrievable should be up to the discretion of the
> provider as long as it can be fitted into a general conceptual framework.
> Even XML Schemas will sometimes be downloaded (e.g. to supply attribute
> defaults), so to force an extra indirection imposes too much.
I consider RDDL a "best practice" and certainly XML-DEV has no ability
to enforce a mandate.
> I don't see that RDDL "solves" the namespaces problem, because the problem
> is not "what is the best thing a namespace URL ought to point to?" but
> do we support what people are doing and want to do with namespace URIs?"
> am not sure how RDDL can flourish if it ignores the people who actually
> overloading the namespace URI for retrieving useful things now.
RDDL isn't ignoring anyone. I'd say that 99.99% of people who follow a
URI expect to see something in a browser -- and the rest have a true need
for the world to be documented. But seriously, the only rational argument
against an indirection provided by a RDDL document is one of efficiency.
Suppose we provide a servlet which sucks in a RDDL directory on the
server and provides a resource based upon an accept header -- forget the q
matching for a moment -- so a client which really does want a particular
content type can ask for it, and the servlet can perform the indirection.
For clients that don't care or don't know what to ask for a readable RDDL
document is returned. For those who care, a particular resource format is
returned (and we can indirect on a x-arcrole: header -- or some such name
for an xlink:arcrole URI a client might include in the HTTP GET request).
Alternatively a client can suck in and cache a RDDL document and then
request resources directly by their own URL. We can even experiment and see
how much if any significant benefit would be produced by server side vs.
client side dispatching.