[
Lists Home |
Date Index |
Thread Index
]
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.
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. Note that during the development of
XHTML there were passionate disagreements on this point
so it's not unreasonable to argue it.
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.
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". One
application of something like RDDL would be to give information
about different versions and flavors of the vocabulary... hmmm.
>Thus, the XHTML namespace does not equate to a single
>vocabulary
I think it does, in practical terms.
>Thus, a namespace is not equivalent to a vocabulary. I.e.
>
> Namespace != Vocabulary
A namespace doesn't equal a vocabulary, but its primary usage
is to label one.
>Is that clearer?
Yes, but I don't buy it. -Tim
|
