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
name:

1. What is the major group that this belongs to (HTML, TEI, DocBook,
   etc.)?

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

-- 
David Megginson                 david@megginson.com
           http://www.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