Re: [metaDataInURI-31]: Initial draft finding for public review/comme nt.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The original question[1] that was the impetus to raise this issue was
"should there be some standard way to encode metadata in URIs"?

I think the consensus is "no". I haven't heard anyone suggesting that,
for example, version information should be encoded in URIs with
"/VERx.y/" as a path component and that the string "/VERx.y/" in a URI
should always be interpreted as the version number of the resource.
I'm sure it would be convenient in some communities if a proposal
along these lines was adopted, but it isn't going to be.

Most of the actual discussion seems to have been about whether or not
one should ever put metadata in a URI and whether or not software
should contain conditional logic that operates on the interpretation
of the URI strings all by themselves.

As to whether or not one should, what could we possibly say? We
certainly can't legislate *against* it. Assignment authorities can use
any algorithm they please.

For example, the XML DTD version of DocBook V4.1.2 is identified by
the following URI (it also has a public identifier, but I won't
digress :-)

  http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd

As it happens, the SGML DTD version is identified by:

  http://www.oasis-open.org/docbook/sgml/4.1.2/docbook.dtd

It doesn't take much cleverness to figure out the likely URI of the
SGML DTD version of DocBook 1.0 (and you'd be right). I don't see how
that does any harm. And the fact that I encoded some metadata in the
URI doesn't obligate me to continue to do so, though I am likely to
since it's a convenient way of carving up the allocation space.

Should software agents make decisions based on the contents of URI
strings? No, probably not. Since there's no *standard* way to
represent metadata, any software that does base decisions on the
content of URI strings is likely to be fairly fragile.

If you wrote a piece of software that guessed that the URI for the XML
DTD version of DocBook V2.0 was

  http://www.oasis-open.org/docbook/xml/2.0/docbookx.dtd

It'd be wrong. (There was no XML version of DocBook V2.0. In fact,
there was no SGML version either, we went from 1.2.1 to 2.1.)

Whether this piece of software is exhibiting a bug or a feature is
likely to depend on your point of view. I think it's a bug, but that's
got more to do with the fact that it's guessing about something than
about how it guesses.

Would it be wrong to design and publish an algorithm for constructing URIs
for a particular kind of resource? For example, if I wanted to be able to
identify the particular elements and attributes of DocBook, could I propose
the following algorithm:

  http://www.oasis-open.org/docbook/components/{version}/{element}[/{attribute}

And then could I suggest that software agents manufacture URIs of that
form, using

  http://www.oasis-open.org/docbook/components/2.0/emphasis/role

for example, to identify the role attribute on the emphasis element in
DocBook V2.0?

Sure I could.

Would it be wrong? I can't think of any reason why it would be. I'd be
entering into an agreement to maintain this scheme with some outlined
persistence criteria, but that's my choice.

This wouldn't generalize. It would pretty obviously be a bug to assume
that the components of HTML could be identified that way, but I don't
see why that's a problem.

                                        Be seeing you,
                                          norm

[1] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0149

- -- 
Norman.Walsh@Sun.COM    | Those who in their youth did not live in
XML Standards Architect | self-harmony, and who did not gain the true
Web Tech. and Standards | treasures of life, are later like long-legged
Sun Microsystems, Inc.  | old herons standing sadly by a lake without
                        | fish.--The Dhammapada
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE/DFGtOyltUcwYWjsRAqnkAJ9cJil60orltUOq+R4VqJYqWibcygCfdC0h
I69aw/vU0KPeHJyx2DPhvT0=
=cBBv
-----END PGP SIGNATURE-----

Received on Wednesday, 9 July 2003 13:32:59 UTC