Re: fundamental difference?

At 01:04 AM 6/3/00 -0400, Tim Berners-Lee wrote:
>It doesn't mean that I'm right and you're wrong, but I think you have a
>fundamentally different perspective of what a namespace is than a lot of
>people on this list.
>
>That may be so.   However, as without that perspective there can be nothing
>built on XML,  for me it is important.

Okay... let's step back a little, since that perspective is not universally
shared.  If you want to build further work on that perspective, you need to
formalize and develop that perspective, getting buy-in and participation on
both the overall perspective and the details from the larger communities
where you mean to deploy that perspective.

It seems that we've exposed a fundamental disconnect that may underlie some
of the uglier battles in the creation of namespaces, and could explain why
the spec says so little about 'what a namespace means'.  While not
necessarily relevant to the 'should relative URIs be allowed as
namespaces', they seem to be the cause of much of the underlying heat on
the issue.

>Yes, I have to tell you, that when I get an invoice in XML and the namespace
> tells me its a invoice then I am interpreting namespace as meaning langauge.
>And folks, so are you.   The XHTML namespace has a big speci defining
>it whaich says more than the list of tags in it.  It is the work of hundreds
>of people and it is the basis for intreroperability betwen clients and
>servers everywhere.

Why does the namespace alone tell me it's an invoice?  Why not context,
DOCTYPE, a basic understanding of the language the creator of the document
wrote the elements and attributes in?  Namespaces are handy in certain
cases, but I think you're making overarching (and unnecessary) claims here.
 The work of hundreds of people is great, but I don't see that as
inextricably linked to a particular identifier.

>Ecommerce will all happen with documnets written in languages.
>The fact that the namesapce defines what those documents mean is that -0 a
>fact.
>That's how everyone I have come across actually is talking about working.
>They aren't alking about exchanging meaningless documents, or having the
>meaning ofth terms conveyed by an out of band telephone call. No sir,
>they are using the namespace name to mean that this document is scalable
>vector
>graphics. On this basis they drasw it rather than pay it.  William Perry
>points out they have the option
>of draing a bill orpaying a picture as an independent agent, but still the
>invoise has
>a meaning and that meaning for an XML+NS document rests on the namespace.

I don't think any of that requires namespaces in the reified sense you seem
to see them.  Allowing that meanings are contingent doesn't explode these
systems, nor does decoupling those meanings from an abstract conception of
namespace.

>Well, documents have moral force, and without a namespace ID they are
>just strings of bits.

Again, you're leaving out lots of parts - context, MIME content types,
doctype, sender-receiver relationships - and from my perspective, namespace
IDs themselves are just strings of bits.  We can imbue those bits with
meaning, but it's not inherent in the bits.

>Too late.  People are already sending XML across the net with meaning.
>maybe we could stop them. maybe we could revoke any meaning associated with
>it.

They're doing that in lots of different ways, though, none of which seem to
demand a reified conception of a namespace.  Namespaces as identifiers only
work just fine for all of those cases, and let people structure meaning on
top of identifiers if appropriate.

>Maybe we could strip the xHTML spec down to the bare syntactic constraints
>or better just a lits of tag names.

The XHTML spec represents ten years of development and practice by an
enormous group of people, not all of whom actually wrote the spec.  The
spec itself probably _could_ be a list of tag names, as the meaning comes
from those shared understandings already.  The namespace just screams "hey!
program!  treat this as XHTML!"  

>The problems is taht at some level the philosophy is orally assumed, for any
>spec.

I think you may have wrongly assumed that far more people share this
philosophy, as it's clear from much writing in the XML community that your
philosophy is not well-understood, even unknown in some quarters I would
have expected to have heard of it.  The oral traditions surrounding
namespaces on XML-dev, for instance, bear little relation to the philosophy
you present here.  That doesn't mean incompatibile technical results; it
merely means that those technical results have to be the result of
compromise and discussion instead of the application of axioms.

>Obviously I assumed too much was shared.  Do you have an alternative basis
>for atributig meaning to an XML document, or are you happy for there to be
>none?

I've got lots of alternative bases, a few of which are noted above.  There
are more than enough practices for assigning meaning to markup, and
namespaces make a contribution to that list.


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Received on Saturday, 3 June 2000 09:18:03 UTC