[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Another look at namespaces
I would like to comment on one of the several issues in this thread. 1. If indeed there are separate languages, where the elements in one require different processing (such as different validation) from elements in another, then the distinct elements of each should be distinguished by different namespaces. 2. If one of the languages is a superset of the other, as Traditional is apparently a superset of Strict, then there is nothing in the namespaces spec per se that prevents a document instance from combining elements from both namespaces. There is nothing in the namespaces specification that requires that all the elements in a document come from the same namespace. One consequence of this is that the superset language (e.g. Traditional) does not need to define its own equivalent of each term in the subset language. The difficulties in doing this today are limitations of the language definition facilties in DTDs. There is not anything that prevents a future schema language from defining validation and schema composition in such a way that use of items from one language within another is convenient, and use of elements and attributes from several namespaces in an instance document is both simple and unobtrusive. -----Original Message----- From: Tim Berners-Lee [mailto:timbl@w...] Sent: Wednesday, September 15, 1999 1:41 PM To: Paul Prescod Cc: XML-DEV Subject: Re: Another look at namespaces Paul Prescod (paul@p...) on Mon, 30 Aug 1999 08:29:53 -0400 said, > There are two separate issues here. Yes. > #1. In 1999 xHTML can either have three namespaces or one. If it has > three then there will be a one-to-one relationship between namespaces > and grammars so that a programmer can know the grammar of the input > data. Programmers that want to treat the three as one will have to do so > by issuing some command to their namespace processor or (better) by > using a namespace processor that recognizes an embedded instruction. [...] > I think that people are really concerned more about the precedent than > today's issue. Yes. It is a question of how namespaces are used. I have no passionate personal concern as to whether XHTML spec defines 3 languages or one, but the HTML 4.0 spec defined three, and XHTML was required to be as direct a mapping from HTML 4.0 to XML as possible. You can dispute (and many do) whether defining both "strict""and "transitional" is useful. (where by "strict" read 'http://www.w3.org/TR/.../strict" or whatever the URI for strict namespace is) Aside from that discussion, let's just use Strict and Transitional as examples if one does have two languages. It is important to realize that these are *different* languages. If you take a Transition document and re-label it as a strict document it can be invalid. Invalid by specification, whether represented by English or DTD or schema. But equally important is what folks are getting at I think when they say they are the "same" language: that Strict is a *subset* language of Traditional. That means, that if you take any valid Strict document, and transform is by changing nothing except the namespace URI from Strict to Transitional, then it *will* always be a valid document in every sense. This applies whether you define validity using just a spec or with the help of a DTD or schema. > #2. In 2000, 2001, 2002, etc. there will be new versions of XHTML. Some > (probably all) of these will be backwards incompatible as every version > of HTML has been backwards incompatible: a document conforming to the > new vocabulary/grammar can break code expecting the old > vocabulary/grammar. Yes, absolutely - leaving aside again the question of XHTML itself and treating it as an example. > It is *vital* that a) there be a way to announce this > backwards-incompatibility and b) there be an infrastructure that allows > a mapping from new to old. The namespace is the obvious way to do the > former. We have no good mechanism for the latter. > > As I've said, this is also necessary for e-commerce and every other XML > application. Yes. > If we develop this mechanism now then the first wave of XHTML software > will be automatically ready for XHTML 2.0 (not to mention e-commerce). I > can understand the wish to delay the problem but it just means that we > cause a train wreck later on. I am deathly afraid, however, that if we > set a precedent of pretending that these three variants are "one > language" we will continue down that path as we develop more and more > incompatible new versions. Yes. We cannot afford to be fuzzy. We must be able to use compatibility where it exists (easily and simply) but absolutely not assume it where we have no reason to. This principle of mandatory extension is something which we tried for years to get into HTTP because we needed it for putting in new mandatory features. In HTML originally I specifically stated that any unknown tag must be processed as though it was replaced by its content. In other words, For all x not in HTML, a<x>b</x>c --> a b c (1) preserved HTML-validity. That was a good thing and a bad thing: it allowed experiments galore. It also alas allowed total ambiguity to arise when e.g. <table> was introduced by Raggett and Netscape and others at the same time. Namespaces fix that directly. It allowed, equally seriously, no way of saying "If you don't understand this feature then you cannot process this document. This is a very important requirement for any language IMHO. In this case, the only information which a Transitional-capable receiver of information needs to be able to process a Strict document is "Strict is-a-subset-of Transition" This gem could be - programmed into a xHTML-specific application or - picked up from a schema or - picked up from the document itself The latter case is useful where you have an in-house subset of a language but you want generic browsers to know that the language can be processed as xHTML. As you say, this is really important for version change. "v2 is a subset of v1" is a rare case which any v2 document can be interpreted as a v1 document. What happens when a version one program meets a version 2 document? a). Halt. "Don't understand". This happens with typical word processors. sometimes this is the behavior you need. b) Know that it is a subset of what you know, and process it. c). Parse it and ignore new features. This can be done by using a separate namespace for the new features, and by saying in some way (which we really need) that it is ok to ignore (replace with contents, or remove: state which) elements in that namespace for the purposes of that document. d) Convert it into a v1 document. [(b) and (c) are actually a special cases of (d)]. In the last case, the application only innately "understands" the v1 language, but the schema includes [pointers to] rules which allow a valid v1 document to be deduced from the valid v2 document. These are rules e.g. of the form (1), or a set of "Optional/mandatory" flags for the elements. Or maybe an XSLT mapping. Or a set of inference rules for RDF. (d) requires that the application-specific processor have at its disposal a nonspecific translation processor of some sort. I would like to see a simple way of defining subset languages introduced with all speed, to allow (a) and (b) for all XML applications. I'd like to see experiments with (c) and (d) too, in particular an early way to define optionalness of namespaces in XML in a particular document. Underlying this is a philosophy about the meaning of a document. As I see it, a document is from the author to the reader, and its job is to convey the intent of the author. When an author uses a defined language, then the author refers to the language-author's definition of terms in the language. When I write you an XML document, then what I mean is what I say, interpreted according to the specifications of the language - the namespace - I use. Of course on the web we don't expect machines to "understand" information in an AI way. We use a version of "understand" which means to be able to translate it into something which it has innately been programmed to process, while preserving in that translation the intent of the author. This may seem a heavy way of defining HTML but think about the international exchange of invoices. The web of meaning between languages is defined by the set of these transformations. The namespaces spec was adamant that you could use namespaces without having to dereference the namespace URI. 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. And this is not mandatory - but is very useful! For example, you can run an xHTML document though any DTD you like if it suits your purposes, but if you want to check whether it is valid xHTML then you should use the xHTML schema which corresponds to the namespace URI. You might of course have a local copy and not actually need to go onto the net to us live HTTP. The exciting use of namespaces in schemas will be when we have schema documents which contain the syntactic constraints in xml-schema language, but themselves use other namespaces to come to express the entity-relationship model of data (rdf-schema), legally appropriate presentation (link to style sheet), financial implication (link to mapping to FSTC echecks or whatever). The functionality which we will be able to build into new languages will grow as the richness of languages to which we can map. > Paul Prescod Tim Berners-Lee not in any official capacity. 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...) 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
|