Database example was: The Kesselman/Connoly proposal

-----Original Message-----
From: keshlam@us.ibm.com <keshlam@us.ibm.com>
To: Simon St.Laurent <simonstl@simonstl.com>
Cc: Michael Champion <Mike.Champion@softwareag-usa.com>; xml-uri@w3.org
<xml-uri@w3.org>
Date: Monday, June 26, 2000 7:55 PM
Subject: Re: The Kesselman/Connoly proposal (was Re: Re Deprecate
/Undefined )


>I'm not sure there is a "Kesselman/Connoly proposal ". My perception is
>that Dan is favoring Deprecate/Undefined, as a way of avoiding having to
>break existing documents. My own preference is for Forbid -- both because
>Undefined is more fragile than I really like, and because Forbid more
>clearly reserves the relative syntax for use if and when someone comes up
>with a meaningful semantic for it.



>Statement of bias: Personally, I don't expect to see such a semantic before
>the XML 3.0 timeframe.

By semantic, I assume you mean what it means.  This is defined in the URI
specification. You don't need to search far - you just have to find a
transition
path to it for those people who have been using something which looks like
a relative URI-reference without that meaning.

>Yes, I said "three".

If this is an indication that, with the relative URIs for namesapce names
having been declared a no-man's-land during peace talks, that you  would
expect that TWO MAJOR revisions of XML would have to happen before
this mess is resolved propoerly,  before anyone could build on top of XML
using the URIs of namespaces?

If that is the feeling of this community, then I think it would be better to
separate such data applications from XML as represented by that opinion as
soon as possible.

>We have yet to see a good
>proposal for why anyone would actually want a relative  reference to a
>namespace.

I tried
http://lists.w3.org/Archives/Public/xml-uri/2000May/0281.html
and I give the relavant extract from that message, cleaned up a little,
below,
at the end of this message.

As fas as I am concerned, that stands as ascenario in which relative URI
references
(treated properly as relative URI references by all parties) are an
advantage.
You may not deem it to be "good" but you can't ignore it.
Please give the namespace name you would suggest as alternative

I think (maybe by projection) that it is similar to the situation in which
Microsoft
didn't actually use relative URIS   (x-schema:#schema) but meant to
(#schema).

The essence is that in some applications, namespaces will be created
with the same frequency and persistence as very closely related data files.

>There have been a few architectural visions proposed, but they
>haven't clearly established a scenario where relative namespaces are the
>proper way to advance their goals -- never mind a complete analysis of how
>that should affect the interpretation of other W3C standards supporting and
>using namespaces.

The latter is trivial.  All processing applications which need the namespace
name just absolutize the URI reference and behave as before.

The former - an architectural vision in which relative URIs are allowed
is simply the consistent invokation of the URI specification by the
XML-Namespaces specification, so the vision is as broad as for
markup on the web.  I don't think that arguing that simplicityt and
consistency is a good idea or that markup languages for the web
are a good idea is useful here so I will let that one go.


>I think it's incumbent upon those who want to introduce a
>concept which has such broad impact to present us with a complete picture
>of what they want to do, why they want to do it, what the alternatives are
>for expressing it, which alternative they've picked and why.


On the contrary, where every thing else in the web uses URI references, (as
does the unix command line) its use should be the default, and it behoves
those who want to make a special case to show why they want to exclude their
use in a particular case.

>Given the current state of the Semantic Web concept, I'd be quite startled
>if any such proposal is ready in less than a year. More likely two.

Please stop trying to tie absolutization on the semantic web!
Just because I happen to be excited about the possibility of logic
languages on the web does not mean that every simple basic thing
I argue for can be construed as being so far in the future.

The proposal could be as short as changing the
"[Definition:] The attribute's value, a URI reference, is the namespace name
identifying the namespace. "
of http://www.w3.org/TR/REC-xml-names/ to

"[Definition:] The attribute's value, a URI reference, denotes the URI which
is the namespace name identifying the namespace. "

The proposal from Andrew Layman et al can be consulted for a more detailed
explanatory version with appropraite warnings.

> And at
>that time, my own instincts suggest we'll discover that making namespace
>delarations relative isn't actually necessary, and perhaps not even useful.


Is it possible for you to find that it "isn't actually necessary" when
someone else
finds that it is is?

In a message penned a little earlier (7:36pm) you wrote,

"The few folks who've said they really do want
the NS declaration to be relative have Big Ideas -- and maybe even
interesting ideas -- but I've seen nothing even vaguely resembling a design
sketch. If they can come back with such a sketch and knock our socks off,
that's great and we can consider extending XML at that time"

Whose socks exactly, and what does it take to knock them off?
Folks on this list have tried argument, humor, example but --
is this going to prove worth the effort?

Tim Berners-Lee


PS:  (In this message I object to Joe Kessleman's invalid arguments against
absolutization. I am still I think happy for relative URIs to be warned
against
as an emergency measure so we can make progress - but not if progress is
then rolled back to some XML 3.0 date!)

________________________________________________________________

The database example extracted from
http://lists.w3.org/Archives/Public/xml-uri/2000May/0281.html

Let us imagine that someone has created a database of employees and offices.
They decide to export this onto the company intranet, and they are using
software which understands XML and xml-schema. This software, attached as
server applet to the web server, provides a web view of the data in XML.  It
creates a namespace specifically for expressing data from that database.
Because it is a server applet it only has control over local URI space, and
it may not even know what the absolute URI of the database is.  Indeed, a
design constraint may be that it is written without knowledge of the virtual
hostname from which it will be served.

It supports the following virtual resources. (Virtual = not stored in files,
generated on the fly)

- the database (say) has URI http://internal.example.com/2000/05/foo . When
asked to render that, the HTTP server will respond with an XML document
pointing users at the various tables and written using the xHTML namespace.
(It references the XHTML namespace of course by absolute URI using the one
in the XHTML spec)
It makes a link to the employees table as "foo/employees".

- the namespace for encoding data from the database is (relative to the
above) foo/ns. When asked to render this by a client understanding XML, a
document is returned written in the xml-schema namespace. (Referenced by
absolute URI). foo/ns defines the datatypes of the columns in the database
and the syntactic constraints for
the serialization of database data represented in foo/ns.  This allows a
syntax checking tool to verify that data documents are schema-valid.  It is
a *represenattion* of the namespace - the bits are returned are not of
course the namespace itself which is an abstract thing, a resource,

- the employee table is foo/employees. This is rendered as a an XML table
with the data encoded in the namespace foo/ns . When asked to render
employees, the server responds with a document using namespace foo/ns, which
it refers to using relative URI "ns".

The server *could* have looked up the original URI with which it had been
invoked, and use http://internal.example.com/2000/05/foo/ns  but  this would
be the first time it has to be aware of its own hostname. Further, as the
namespace is a custom one for this particular database, it is as persistent
or transient as the data itself. So there is no "persistence" argument for
using a relative URI.  There is a data management argument for using a
relative URI.  (This also applies in the case of the same thing being
written by a human).

So here we have a one-off namespace made quite automatically by the database
application. Until and unless the user has made some connection to other
information, then it stands alone with the data. It is intimately connected
with the data, they are published together just as an HTML file and an
embedded image.

The above is an example in which the use of a relative URI reference  for a
namespace is preferable to absolute URI.

Tim BL

Received on Friday, 30 June 2000 10:43:19 UTC