[
Lists Home |
Date Index |
Thread Index
]
On 2002-02-20 21:02, "ext Tim Bray" <tbray@textuality.com> 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@nokia.com
|
