Lists Home |
Date Index |
- From: David Megginson <email@example.com>
- To: XMLDev list <firstname.lastname@example.org>
- Date: Sat, 11 Sep 1999 06:37:45 -0400 (EDT)
[I'll answer this one question, and then will try to shut up again.]
Sebastian Schnitzenbaumer writes:
> > Then why not allow the html:version attribute on *any* HTML
> > element? Then you can specify version information for subtrees
> > as well as for an entire HTML document.
> This mechanism would then be similar to namespaces in design.
Well, in scope, at least...
> You are suggesting that the namespace is the highest level of
> hierarchie, and every XML grammar that has multiple variants shall
> introduce its own mechanism to distinguish the variants as the
> second level below namespaces.
Only if they need to. The problem is that there are at least two
different kinds of information needed about an element or attribute
1. What is the major group that this belongs to (HTML, TEI, DocBook,
2. What is the special variant (version/flavour) that this belongs to
(XHTML 1.0 strict, etc.)?
No matter how we slice it, *one* of these is going to be easy for
programs to discover and one of them is going to be harder. Using a
single XHTML Namespace URI and an html:version attribute makes #1 easy
and #2 only slightly more difficult; using multiple XHTML Namespaces
and complex schema/RDF constructions makes #2 easy but #1 relatively
much more difficult.
So the question is not whether #1 or #2 should be omitted (both are
needed), but which one most applications will care about. My guess is
that most applications will care about #1, and that applications that
need #2 will be sophisticated enough anyway that checking another
attribute won't be a big deal.
> XHTML is a language with quite some history. I a few years, it is
> likely that other XML grammars will have the same situation like
> HTML (SMIL, for instance). I feel unconfortable introducing such a
> mechanism now just for XHTML where it will be likely that a similar
> mechanism will be needed in different languages as well. In the
> end, the version attribute will be used in conjunction with the
> xmlns attribute for many popular languages. So then why have two
> mechanisms, where one is global and the other one is always
> language-specifc, but both are in the same space.
There's good precedent -- think of Perl packages, for example, which
have a single, persistent package name across all versions and then
use a conventional $VERSION attribute, as in the following example:
$VERSION = "0.2";
All well-behaved Perl packages use the $VERSION attribute the same
way. That way, applications written to work with XML::Writer 0.1 will
continue to work with XML::Writer 0.2, but applications that need to
be sure can check the $XML::Writer::VERSION attribute.
In other words, this suggestion is well-proven in major-scale,
real-world implementations (last I heard, Perl was still the driving
engine behind Amazon.Com and Yahoo!, for example).
All the best,
David Megginson email@example.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)