RE: Another look at namespaces
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format