Re: [office-comment] Section 1.5 - implementations SHOULD use thenamespace prefixes given.

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

On Mon, 2004-10-25 at 10:13, David Faure wrote:
> On Monday 25 October 2004 17:24, Uche Ogbuji wrote:
> > [...]
> > I also agree with Michael that disallowing people from using the default
> > namespace will result in needless space bloat across the board.  I'd
> > certainly prefer my OOXML application to use 
> > 
> > <styles xmlns="urn:oasis:names:tc:openoffice:xmlns:office:1.0">...
> > 
> > rather than
> > 
> > <office:styles
> > xmlns:office="urn:oasis:names:tc:openoffice:xmlns:office:1.0">...
> 
> This is rather about 
> <?xml version="1.0" encoding="UTF-8"?>
> <office:document-content xmlns:office="urn:oasis:names:tc:openoffice:xmlns:office:1.0" [...]>
>   <office:styles>
>      ....
>   <office:automatic-styles>
>      ....
> etc.
> 
> I.e. the definition of the 'office' prefix (for namespace-aware parsers) is done only once.
> -> not much bloat.

There is plenty of bloat.  The prefix has to be used everywhere.  All
element type names have 7 redundant bytes.  This can really add up.

I never meant to suggest anyone would have to repeat the namespace
*declaration* in every element.  My apologies if my example (which was
thus merely because I couldn't remember the top-level element name off
head) gave the wrong impression.

But my point is still quite valid.


> It also avoids some name clashes which would happen with some
> element names -- the point is that the OOXML specification defines many namespaces
> (and prefixes), not just one.

Sure, but I argue that we either use namespaces, or don't use it, and
don't invent a broken hybrid between these two options.  There are many
ways to avoid name clashes without using XML Namespaces.


> The elements from the various namespaces are really
> intermixed, one can't just use a default namespace, most of the time.
> Example:
>   <office:text>
>     <text:numbered-paragraph text:level="1" text:style-name="L1">
>     ...
>   </office:text>

This is very ugly markup.  Whatever is wrong with:

  <text>
    <numbered-paragraph level="1" style-name="L1">
    ...
  </text>

?

> And this (always using the same prefixes on saving) is what the implementers
> of the spec (i.e. OpenOffice.org and KOffice) do currently, so I don't think 
> mandating this would be a big problem. Yes, I can see which advantages
> real namespace support brings (well, for those writing XML by hand....)
> but the disadvantages seem bigger currently, as long as namespace-support
> isn't that widespread in all the XML tools people use.

Actually, namespace support *is* very widespread, whether you like it or
not.  As a good example, XPath, XSLT, WXS, RELAX NG, DOM (Level 2), SAX
(2.0) etc. all support namespaces.  I actualy find it unusual these days
to come across tools that don't.  I'm not a KDE user, so perhaps I'm
missing a perspective, but I'm quite familiar with the state of the XML
art in many other technological areas.

But none of that matters.  I think it's perfectly reasonable to lower
the bar for implementation by not using namespaces.  But I do not think
it is reasonable at all to confuse the heck out of the issue by falsely
pretending to use namespaces.  So if we're not using namespaces, I think
we'd better leave colons out of XML names, and don't even contemplate
any attributes starting with "xmlns".


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A hands-on introduction to ISO Schematron - http://www-106.ibm.com/developerworks/edu/x-dw-xschematron-i.html
Schematron abstract patterns - http://www.ibm.com/developerworks/xml/library/x-stron.html
Wrestling HTML (using Python) - http://www.xml.com/pub/a/2004/09/08/pyxml.html
Enterprise data goes high fashion - http://www.adtmag.com/article.asp?id=10061
Principles of XML design: Considering container elements - http://www-106.ibm.com/developerworks/xml/library/x-contain.html
Hacking XML Hacks - http://www-106.ibm.com/developerworks/xml/library/x-think26.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/