Re: TB16 Re: Comments on arch doc draft

On 2002-07-03 0:47, "ext Tim Bray" <tbray@textuality.com> wrote:

> 
> Bullard, Claude L (Len) wrote:
> 
>>> I stand by my concerns in regards anybody who has high-value reference
>>> information which would increase the usability of their offering and
>>> declines to make it part of webspace.
>> 
>> You do not deal with high security information or systems that must
>> produce and maintain it, or policies that govern such systesm.
>> You are not competent to make that call.
> 
> In fact I have done business both with Fort Meade and the OSD and I
> understand something of those issues.  If you send me XML to process,
> and you put that XML in a namespace, and you give the namespace a name
> that makes it impossible for me to dereference it to help figure out
> your data, I'm going to be annoyed.  Even if it only says something like
> "The contents of elements in this namespace are encrypted and must be
> maintained in canonical form" or "For more information about this data
> call (703) 482-0623 and ask for Ernie" that is much better than nothing.
> We're trying to write rules for data that's out there on the Web. -Tim

Well, what if (a) the namespace name is an http: URL and (b) there
actually is a namespace document accessible at that URL but (c) that
URL is behind a firewall and not publically accessible, since, after
all, this is sensitive material. That's not going to do you any more
good than not having a dereferencable namespace URI to begin with.

(Yes, some folks may argue that if it's behind a firewall it's not
"on the web" but I don't hold that view -- accessibility can be
affected by all sorts of conditions, and I doubt that anyone would
say that some web page that is password protected but publically
and globally accessible otherwise is not "on the web")

The real problem is that namespace names and namespace documents are
insufficient to do what folks want them to do. This is because
XML and other web documents do not actually specify the particular
document model to which they conform, and thus one has no real
means to know for certain, given a particular XML instance, what
constraints or interpretations apply.

Take XHTML as an example. There is one single namespace URI, but
three functional vocabularies and three document models, and
the structural and semantic definitions of some terms differ
between the different document models. It
is impossible to know, based on the identity of the
root element term, which document model applies, and even
if each document model has associated with it various schemas
via some namespace document, you don't know which schema the
instance must conform to.

C.f. http://lists.w3.org/Archives/Public/www-tag/2002Feb/0137.html

A namespace name does not identify a single vocabulary, or a single
document model, or a single schema, etc. There can be multiple
vocabularies all sharing terms ground in the same namespace, and
there can be multiple document models using terms from the same
vocabularies, and of course, there can be multiple schemas of
various languages/encodings defining those terms, vocabularies,
and document models. So neither an application or a human getting
some XML instance is *not* going to be able to figure out from
that instance itself which document model, which vocabulary,
which schema, etc. applies.

Much of the intended benefit of namespace documents retrievable
from namespace name URLs is an illusion. It's wishful thinking
that the currently deployed web architecture does not provide
for, and changes to the architecture to ensure such behavior
would be IMO far too drastic, even for the TAG to make.

Yes, we need a consistent, standardized way to obtain information
about terms, vocabularies, document models, schemas, etc. -- really
about any resource whatsoever -- but overloading namespace names
to serve as the mechanism for providing that information is IMO a
short sighted hack that won't work generically for the complete
scope of the *currently* defined and deployed web.

There is a fundamental problem with the current web architecture
in that it does not make any distinction between a representation
of a web-accessible resource and information *about* a resource,
whether it is web-accessible or not.

A term in some vocabulary is an abstract resource, and if the
URI denoting that term dereferences to anything, then that is
a bug, since it is impossible to actually obtain a representation
of an abstract resource. Similarly, a namespace is an abstract
resource, and thus, if a URL is used for the namespace name,
having it resolve to anything is IMO a bug, just as for any
abstract resource.

One solution to this problem would be to extend HTTP to provide
support for the retrieval of information about resources as
well as web-accessible resources themselves.

C.f. http://lists.w3.org/Archives/Public/www-talk/2002MayJun/0039.html

In this fashion, one may describe any resource whatsoever, even
a namespace, without requiring that the URI used to denote that
resource resolve to anything, and use HTTP to execute queries
about particular resources, such as namespace names.

I consider this to be a much better solution, which does not
blur the distinction between resource and information about a
resource -- as the present proposal of dereferencable namespace
URIs does.

Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 3 July 2002 04:04:27 UTC