OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: RFP: Namespace URI for HTML

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: XMLDev list <xml-dev@ic.ac.uk>
  • 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:

  package XML::Writer;
  $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                 david@megginson.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS