Another look at namespaces

[Ann Navarro]

At 12:06 PM 9/16/99 -0400, Simon St.Laurent wrote:
>At 08:30 AM 9/16/99 -0700, Andrew Layman wrote:
>>[Someone] wrote that, although a schema may be somehow associated with a
>>namespace, the "meaning" of markup will be determined in a number of ways
>>such as style sheets, or procedural code, or maybe the schema.  I believe
>>this understates the importance of the schema.  A schema makes a
>>contribution to the Infoset. It does this by providing default values and --
>>under some recent proposals -- by indicating type information, which may be
>>considered also a form of default value.  Elements defined by a schema, when
>>used in an instance document in a validating processor, will have these
>>default values available, and this fact is pertinent to the author of the
>>document.  This means that an element is incompletely read if the schema for
>>it is not read. 
>
>With all due respect to Andrew Layman, I find this to be a gross
>overvaluation of schemas, and a substantial contrast with both the XML 1.0
>approach (which doesn't require validation) and with Tim Berners-Lee's
>comments, which included:
>
>>However, as we define languages for talking about languages
>>(XML and RDF schemas for example, even style sheets)
>>the document corresponding to the namespace URI becomes
>>the place where the namespace-author can put *definitive*
>>information about the intent of the namespace.
>
>This seems to leave the possibility _wide_ open that something other than a
>schema is lurking at the URI identified by the namespace.  At the very
>least, there are multiple schema possibilities - XML and RDF, as noted
>above, and possibly even DTDs.

Perhaps we need to step back and take off some of the "black and white"
blinders that seem to be on here (no personal slight to Simon intended). 

I don't read Andrew's comments as saying "schemas and only schemas" can do
what he proposes. Therefore nothing in that conflicts with Tim's assertions. 

It's very clear that additional functionality is desired and needed (as I
suggested some weeks ago now (an unfilled need)), just how that may come
about is yet to be determined. 

Nothing in the current proposals being debated sets functionality. Instead,
it provides granularity in namespaces making a nod toward the possibility
of additional functionality. 
It may turn out to be unnecessary, but as I've said before, I believe it
easier to remove that granularity later (or simply ignore it), than it will
be to put it back in at some later date. 

Ann



---

Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML

Founder, WebGeek Communications            http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education             http://www.hwg.org/services/classes





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)