Re: Re: [namespaceDocument-8] 14 Theses
On 2002-02-20 21:02, "ext Tim Bray" <tbray@t...> wrote: > At 04:03 PM 20/02/02 +0200, Patrick Stickler wrote: >> Take XHTML for instance. We can talk about the Strict >> vocabulary, or the Transitional Vocabulary or the >> Frameset Vocabulary. These are separate functional >> vocabularies. > > Not really. If I see <html:img src="whatever" /> it's > reasonable to conclude that "whatever" is the URL of > an image. The differences between the 3 dialects of > HTML is they are increasingly large supersets of each > other, and that some elements have different content > models, i.e. validation constraints. Hmmm... so a superset is not a separate vocabulary? Is 'frameset' part of the Strict vocabulary? No. I understand your point. There are vocabularies and vocabularies, and one can talk about the meta-vocabulary of XHTML 1.0 meaning all terms defined by the spec, etc. but what if I want to talk only about the Strict vocabulary -- such as, thus CSS stylesheet provides presentational semantics for the Strict XHTML vocabulary. The namespace does *not* denote that specific vocabulary. And it *is* a specific vocabulary. > However, the basic "meaning" and processing of an > <html:img> or <html:ul> element is pretty uniform, i.e. > for most practical purposes HTML can be considered to > be a vocabulary. Practical for whom? A human? A browser? Any arbitrary software application? I agree that there is consistency of semantics across the dialect specific vocabularies, but that doesn't mean the vocabularies are identical. > Note that during the development of > XHTML there were passionate disagreements on this point > so it's not unreasonable to argue it. Glad to hear I'm not being unreasonable (for a change ;-) > I think that there are always going to be variations > and dialects and versions and so on at increasingly > fine levels of granularity, but by design and for > the kinds of practical purposes that programmers care > about, namespaces label vocabularies. The problem is that even if namespaces corresponded to single vocabularies (and I don't think they do) vocabularies do not correspond to single document models and programmers really are concerned with document models, not vocabularies. I don't care what an element is called, only that I know what to do with it in a given context. From a programming perspective, I see namespaces as irrelevant. They're just punctuation that provides globally distinct names. It's the context of how those names are used that matters, and that depends on doctypes, content models, etc. Stylesheets may reference elements and attributes by name, but context is critical, and one crafts stylesheets by document model, not by vocabulary. If a stylesheet is shared across a vocabulary, it is only because all the content models are compatable but introduce an incompatable content model and you'll quickly specialize stylesheets accordingly. Since it is clearly demonstrated in XHTML that one cannot know the content model of an element from its namespace qualified name, there is no practical significance to that namespace insofar as interpretation of that element is concerned. Yes, it's convenient for humans to have few namespaces, both for management and markup ease of use, but I don't see the namespace as bearing the semantic significance that you seem to ascribe to it. > To *completely* identify a markup vocabulary for the purposes > of every conceivable application would require combining a large > number of pieces of metadata - talk to anyone who's ever maintained > processing filters in a complicated publishing application. The > key finding around namespaces is that for a large number of > practical purposes, namespaces provide a course-granularity > way of asserting "this is HTML" or "this is SVG". Or, "this is XML Schema"... oops, nope, multiple namespaces there... Or, "this is PRISM"... oops, nope, multiple namespaces there too... Again, I understand you want there to be some kind of 1:1 correspondence between namespace URI and model/vocabulary/doctype/whatever, but I just don't see such a thing insofar as the architecture is concerned. I'm not saying that it's not useful to treat namespace URIs as a convenient point of reference for gathering a bundle of resources which have some relation to that namespace (or rather, to the terms grounded in that namespace). But the namespace itself is not, and should not, be required nor expected to bear the semantic and functional significance that you seem to expect from it. What matters is the functional vocabularies, document models, etc. not the punctuation that keeps names from colliding. Let's give consistent URIs to those trully interesting things and let namespaces do their humble and simple job. Providing spaces for names. > One > application of something like RDDL would be to give information > about different versions and flavors of the vocabulary... hmmm. Information about those interesting things and their relations is valuable, important, and needed, but such information is not inherently bound to the namespace itself. Nevertheless, as I stated above, a namespace URI is a convenient point of intersection for referring to and describing such related resources, and a namespace document could be a reasonable interim solution for providing access to such knowledge. Though I would expect that RDDL would have to be extended to support (a) arbitrary URIs as names of resources, not just IDs and (b) the ability to define arbitrary properties for such resources. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@n...
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