Re: The 'resource' identified by a namespace name URI should be the namespace

-----Original Message-----
From: John Cowan <cowan@locke.ccil.org>
>What URI spec?  The only one I know of is RFC 2396, which says:
>
># In many cases, different URI strings may actually identify the
># identical resource.


Ouch. Ok, let's stop and fix RFC2396. Shouldn't take long.

>> Suggest that the URI of something given by a URI-reference is anything
>> other than the URI defined in eth URI spec as that referredto by the URI
>> reference
>> would be spilitting hairs to a fine degree indeed.
>
>To be sure.  But what is to be done?  Insisting on treating namespace
>names as URI references to the namespaces (which implies the need for
>RFC 2396 resolution, alias "absolutization", to determine namespace
>identity) is generating howls of protest.  I'm offering a way out
>of the dilemma (or trilemma, if you count the "forbid" position).


It also prevents the namespace URI being usefully dereferenced,
as dereferencing it will get only the namespace name, and never any other
information about eth namespace.

>> Let's say it has an identifier and a title.
>
>Okay, fine.  Talk about people rather than books then; your *name* is
>"Tim Berners-Lee", not some URI.
>
><ad-hominem>


excuse me.

>> John, normally you are the voice of reason but here wit this data:
>> idea I fear you really have gone off at a tangent!  :-)
>
>*shrug*.  Going off at a tangent may be the only way out of an intolerable
>orbit around the same problem.
>
>>   The data: URI scheme
>> has a significance, that a data:,foo URI identifies that resource whose
>> *representation* (not name) is the string "foo".
>
>So I am conflating, for namespace purposes, the entity body with the
>name property.  That may produce more useful results *in this case*
>than conflating the namespace's name with its URI.
>
>> If and when "foo" in some language is a representation of a namespace
>> then that would be a namesapce identifier.
>
>Eh?  "foo" is a valid namespace name already.


But it is not a representation.

http://www.w3.org/tim.jpg may be a name of a picture of me, but
feliuqwxfhlqweunfclrfnglwrufcgnleidgufxhqwifusn78r1237s1r695hfn6j458123y90em
s1234d3cb13
rae238n7js12drxt38r77dr06 might be a (encoded) representation.

>> I suppose (correct the details but get the gist)
>>
>>     data:application/xml-schema,<schema></schema>
>>
>> given the appropriate escaping of the <> could be used as a definition
>> of an empty namespace.
>
>Here comes the namespace-name-ought-to-retrieve-a-schema red herring
>again.

Just the representation-of-a-resource-is-a-representation-of-a-resource
thing.
I keep falling back on that -- so you you eevry time you retreive our home
page and don't get
a bowl of dishwater or a stirrup.

It doesn't have to be a schema. It could as I have said in one of my now
dusty
replied to this idea,

data:a-namespace-john-though-would-be-useful-at-ccil.org-on2000-06-02-at-03-
00

which at least is a representation of the namespace and makes an attept to
be globally unique.

But --- ah-ha!  Hoe about larry's very sensibelnote that a good namespace
description
should include its own definitive URI?  How would you put *that* in a data:
URI, huh? :-)))
Something Goedelian would be in order...

>I think talking about this vision simply undercuts the rest of
>your case.  (Anyhow, as best I understand it, schemas apply to documents
>or document fragments, and can easily describe more than one namespace.)


If a namespace does not have a schema which describes the syntaxof the
language
then we are in a sorry state.
We could go into the "I can apply whatever schema I like to a document"line
but
it wouldn't change the usefulness of having a schema for a namesapce.

>> If I had a key to turn all the messages on the list which mentioedn
"data:"
>> a very pale shade of gr[e|a]y I would use it.....
>
>Fine.  Then feel free to stay stuck, and leave your organization
>wedged again because of irreconcilable differences (does the phrase
>"HTML 3.0" suggest anything?).


Are you really sugegstingthat data: is the only way out?  I guess so.

></ad-hominem>
>
>--
>John Cowan                                   cowan@ccil.org
> Yes, I know the message date is bogus.  I can't help it.
> --me, on far too many occasions
>

Received on Saturday, 3 June 2000 01:17:31 UTC