How about over 1,000,000 XHTML Namespace URIs?

Thu Sep 2 00:06:47 BST 1999

As someone said (and it wasn't Bill Joy who said it first,
despite what someone said here the other day!) there are
only three interesting numbers in computer science:  zero,
one, and many (including an infinity).

If the XHTML WG doesn't want one namespace (like us rational
folk on this list :-), and we don't like to see an unbounded
number of namespace IDs ...

Perhaps the right answer is zero:  just take the namespace
URI out of the XHTML spec completely.

- Dave

p.s. I think the actual formula is a bit less than N-squared;
    N, plus N-1 combinations of the namespaces that are "all
    but one of them", and so on.  Regardless of what the real
    formula is, it's clearly a nonlinear growth.

David Megginson wrote:
> 
> Hunter, David writes:
> 
>  > In other words, any application which is working with XML can just
>  > look for that namespace and say "oh, this element is using XHTML.
>  > I'll hand it off to the XHTML application to process".  If we use
>  > separate namespaces, then any application which may have XHTML to
>  > process will have to know about all of those namespaces.  Perhaps
>  > not a big deal, if only those three namespaces are ever used, but
>  > perhaps a huge deal if more flavours of XHTML are created, or the
>  > namespaces are versioned.
> 
> In fact, there could end up being an exponential explosion of
> XHTML-related Namespaces, depending on how the HTML WG intends to
> proceed (it's not explicit in the publicly-available XHTML documents,
> and I hear contradictory things from the WG members).
> 
> What happens when a vendor wants to create a new element that will
> appear in, say, an HTML paragraph?  Obviously the new element itself
> (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a
> different Namespace -- that's the whole point -- but will the
> containing paragraph have to be in a different Namespace as well?  In
> other words (assuming that XHTML is the default Namespace) can we have
> 
>   <p>Today, President Clinton visited the finger lakes.
>     <ra:videoclip src="clinton.ram" />.</p>
> 
>   <p>Economic indicators are down.
>     <ms:spreadsheet src="stuff.xls" />.</p>
> 
> or does it have to be this?
> 
>   <ra:p>Today, President Clinton visited the finger lakes.
>     <ra:videoclip src="clinton.ram" />.</ra:p>
> 
>   <ms:p>Economic indicators are down.
>     <ms:spreadsheet src="stuff.xls" />.</ms:p>
> 
> (And, of course, an <ms:li> to hold the <ms:p>, and an <ms:ul> to hold
> the <ms:li>, and an <ms:body> to hold the <ms:ul>, and an <ms:html> to
> hold the <ms:body> -- it will always necessarily bubble to the top
> <html> element).
> 
> If the HTML WG takes this (terrifying) path, then what happens when a
> Web author wants both extensions in the same paragraph?  <ra:p>
> doesn't allow <ms:spreadsheet>, and <ms:p> doesn't allow
> <ra:videoclip>, so it looks like she's somehow expected to invent yet
> another Namespace herself:
> 
>   <my:p>Today, President Clinton visited the finger lakes.
>     <ra:video-popup src="clinton.ram" />.  Economic indicators are
>     down. <ms:spreadsheet src="stuff.xls" />.</my:p>
> 
> My math sucks, but as far as I can figure out, that means that the
> number of possible HTML-related Namespace URIs will end up being not
> only three, but about two to the power of the number of parties who
> decide to create extensions (and that's assuming that each vendor
> creates only a single Namespace).
> 
> That means that if only 20 parties create extensions for use in XHTML
> documents, we will necessarily end up with over 1,000,000 variants of
> the <html> element.
> 
> That's an awful lot more than three extra lines of code, whatever the
> software infrastructure.
> 
> All the best,
> 
> David
> 
> --
> David Megginson                 david at megginson.com
>            http://www.megginson.com/
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

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