OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: simple question on namespaces.

[ Lists Home | Date Index | Thread Index ]
  • From: Arjun Ray <aray@q2.net>
  • To: xml-dev@lists.xml.org
  • Date: Thu, 28 Dec 2000 21:41:08 -0500 (EST)

On Thu, 28 Dec 2000, Tim Bray wrote:

> I think a helpful question is "What can you do with little chunks
> of XML when they *don't* have names unique across the Net?"  The
> answer is "Not much."

What can you do with little chunks of XML when they don't have 
meaning *shared* across the Net?  Not much, again.

> Hence, namespaces, and if all they ever did was provide names,
> that'd be fine.

Only to those who already know what those names mean.  In a public
environment like the Net, where the point is to agree on and share
definitions, a "controlled vocabulary" without a means to verify
formal validity is magnificently useless.  

Another "blast from the past" (also indirectly addressing PaulT's
fears about a Tool X being inevitable):

:> I do not expect that a namespaces NSDef can be dereferenced to 
:> obtain a schema. [...] The immediate use I see namespaces put to 
:> is recognition:  Programs can test names to see whether they 
:> match a specific namespace and local name, thereby distinguishing 
:> names that would be otherwise conflictingly ambiguous.  For 
:> example, a processor looking for a MathML DIV element could 
:> recognize it, and distinguish it from an HTML DIV element, 
:> without reading any schemas at all 
: But how does a processor know that "DIV" is a valid name within the
: MathML name space unless there is an authoritative definition of
: what the vocabulary of type names is within MathML? [...] you can't
: claim that a name space is controlled unless there is a defined and
: standardized way to define the vocabulary and the name space
: proposal does not define one (even though XML does: DTDs). 
: Either the NS URI must *always* points a formal definition of the
: vocabulary (not schema) of the name space so that you (and your
: processors) can reliably examine that definition to validate that
: names you've encountered are really in the vocabulary or you can
: never know for sure that a given name is "supposed" to be in a name
: space because even if there is a resource at the end of the URI,
: there's no standardized definition of what you might get, so can't
: trust that you'll ever get anything useful, if you get anything at
: all.
: You might know that, yes, "DIV" is defined by MathML because you
: happened to have lunch with the MathML team and they told you that,
: but you don't know that "Farglebarp" *isn't* in the MathML
: vocabulary and therefore, should you encounter MathML:Farblebarp,
: you won't know if you're at fault for not knowing about the
: Farglebarp tag or if the document author is at fault for misspelling
: ForgleBurp as Farglebarp.  In addition, without an authoritative
: definition of the vocabulary, you can't prove to anyone else that
: your support for the DIV element is in fact appropriate because you
: have no authority to point them to to prove that DIV is in the
: MathML vocabulary and that you didn't misread the name of the DIVE
: element.
: Without a controlled vocabulary, a name space is, at best, a private
: agreement among a bunch of people about what the names are (and
: possibly how to interpret things with those names), at worst it's
: just a mishmash of no reliable value.  There's nothing wrong with
: private agreements, but there doesn't seem to be much point in
: creating a *standard* designed to enable *interchange* that doesn't
: provide for *public* agreements.
: For example, if some company starts using a name space prefix but
: doesn't define its vocabulary in some standardized way (so that any
: conforming tool can interpret it and validate against it), how can
: you ever know if you've handled all their names if you're tryin to
: compete with them by providing support for their data elements? You
: can't.
: In addition, how can this company prevent others from spoofing its
: name space? For example, a competitor could cause its tool to
: produce documents that used the company's name space with names that
: the company hadn't defined. When user's complained that the
: company's tool didn't read the documents produced by the 
: competitor's tool, the competitor could claim that it's not their
: fault, the names are in the company's name space and they should
: handle them.  This probably seems far fetched, but it could happen
: (or something more devious and clever).  In any case, the user would
: have no way of knowing which company was lying.

"Follow The Money".  It was scripted a long time ago...



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS