Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [Fwd: ATTN: Please comment on XHTML (before it's too late)]
 David Megginson wrote: > > W. Eliot Kimber writes: > > > As I said in my post, the reverse is possible: a semantic definition > > (e.g., XLink, RDF, XHTML) can state a binding as part of its > > specification (which is exactly what the XLink spec does), but you have > > know about that statement before you start processing a document. To do > > that, you have to read the spec. Once you read the spec, the use or > > non-use of name spaces is irrelevant for the purpose of recognizing > > element types defined in a given spec--there are any number of ways > > names can be disambiguated or bound to name spaces. The namespace > > mechanism is only one, and it's a particularly weak one at that. > > The first part of the statement is a truism -- with few (if any) > exceptions, there are always different ways any standard could be > implemented. IP could have been designed dozens of different ways, > but that does not make IP irrelevant. My point is that namespaces, by themselves, don't help (or hurt) in the recognition of names that you know--thus they are irrelevant to the problem of name recognition. Once you've read a particular spec, you know how that spec defines names that you can recognize. Given the name of a name space, it is impossible to know in the general case what semantic definitions, if any, might relate themselves to that name space. So you always have to have come across the semantic spec first (or be lucky in your search of available documents). If the spec you have (or find) uses namespaces, fine, now you know, but if it doesn't, you know that too. Thus, there's nothing magical about namespaces with respect the problem of name recognition. And there are a lot of things that are suboptimal about name spaces (such as no way to map a single element to names in multiple spaces). > In fact, SGML itself (and XML 1.0) define only names scoped to a > specific document type, so there are two types of a-priori knowledge > necessary to recognize names: > > 1. You have to know (somehow) what the document type is (as Eliot has > often pointed out, the DOCTYPE declaration doesn't help); and > > 2. You have to know (somehow) what the element or attribute name > means. > > There have been two significant attempts to remove the first of these > problems, so that arbitrary names can be recognized in any document: > Architectural Forms and Namespaces. To establish names that can be > recognized outside of document types, it is necessary to make them > globally unique: Architectural Forms does so by associating each name > with a formal public identifier, while Namespaces does so by > associating each name with a URI. > > Neither Architectural Forms nor Namespaces can offer a solution to #2 > -- after all, the range of possible meanings is potentially infinite. Not quite true--the key difference between architectures and name spaces is that the architecture mechanism provides three things that the namespace mechanism does not, including as much of the solution #2 as you can get in this context: 1. A formal and standardized mechanism for defining the vocabulary of names used in an architecture (architectural DTDs defined using DTD declarations as standardized in ISO 8879 and XML 1.0 Rec) 2. A formal and standardized mechanism for binding a document to the *semantic definition* of the architecture. That is, the external identifier for the architecture *by definition* points to the documentation of the semantics for that architecture. That's the best that *anyone* can do. Once you get to the documentation, it's up to you to interpret it. The documentation can include both machine-readable formalisms (e.g., schemas of some sort) and human-understandable prose. But note what this means: having come across an architecture use declaration, I can get to the definition of the architecture if I can resolve the external identifier. Point of fact: The external identifier for an architecture need not be a public identifier. It can be any form of external identifier, including a URL. In fact, it probably should *always be* a URL so you have some hope of finding the damn thing. 3. A formal and standardized mechanism for defining type hierarchies of element types (architectures derived from architectures). Thus, while name spaces and architectures are both fundamentally about names, the namespace mechanism provides only for the uniquification of names, while the architecture mechanism provides for that as well as the other things you need. Note that there is no necessary conflict between name spaces and architectures--they use different syntactic mechanisms and could be used together, either synergisticaly or not. There is also no conflict between architectures and XML Schemas--I would expect XML schemas to be a core part of the definition of the semantics of architectures and I would expect XML schemas to provide better mechanisms for what architecture *syntax* does today. But it is not fair to say that name spaces and architectures solve *exactly* the same problem. The problem that name spaces solve is a proper subset of the problems that architectures solve. Cheers, E. 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
|
|||||||||
