Re: SVG and MathML in text/html

But what about outside the "open web" platform?  Can we safely say
that we don't care about name-collisions?

See the XAML <Path/> element:
http://www.longhorncorner.com/UploadFile/mahesh/XamlPath06102005084852AM/XamlPath.aspx

Case insensitivity would be a problem because of that.  Microsoft
would have had to rename their element to something else because SVG
got their first?

HTML and XUL and XAML and OpenLaszlo and maybe others have a <button>
element too...

Not that you'd necessarily be inter-mixing these, and maybe I'm
"cheating" by using standards that aren't considered part of the "open
web" strata - but namespaces do provide a way to specify in a
non-ambiguous way which vocabulary you're using.

Regards,
Jeff

On 3/11/08, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Mar 10, 2008, at 23:06, Julian Reschke wrote:
>
>  > Henri Sivonen wrote:
>
> >>> Atom, for instance, works much better.
>  >> http://hsivonen.iki.fi/atom-xhtml/
>  >
>  > It does work better.
>  >
>  > Yes, there may be clients that are broken.
>
>
> And why might that be? Perhaps XML is tough.
>
>
>  >> Putting all the element names from the Web platform languages
>  >> (XHTML, SVG, MathML) into a single space of XML element names
>  >> without any URI binding mechanism. That is, if HTML defined
>  >> "table", it is taken and MathML should define "mtable".
>  >
>  > Doesn't scale. How do you add a new vocabulary? Don't say you don't
>  > need to in the future.
>
>
> In the past decade, the vocabulary of the Web platform has been
>  extended by a whopping two additional element sets: SVG and MathML.
>  Next XBL2 may join the platform.
>
>  Given that this is the actual rate of vocabulary growth we got *with*
>  Namespaces in XML in place, it seems clear to me that as far as the
>  Web platform goes, Namespaces in XML is premised on a totally wrong
>  projection of the rate of growth and, thus, solves a problem we'd not
>  really be having.
>
>  In the case of MathML, the convention of starting element names with
>  "m" would already be sufficient for avoiding collisions with HTML. As
>  far as MathML goes, Namespaces in XML is just a superfluous
>  complication.
>
>  In the case of SVG, the element name overlap with HTML is small and
>  mostly about duplicating the elements. Had Namespaces in XML been
>  absent, SVG could easily have been designed not to clash with HTML in
>  a bad way.
>
>
>  >>>>> Maybe it's because I'm used to writing SVG, but I really don't
>  >>>>> have a problem with the concept of mixed namespace content.
>  >>>> I have a problem with namespace URIs every single time I need to
>  >>>> deal with XHTML, SVG, etc. I always have to waste time looking up
>  >>>> and URI to copy and paste because trying to go by memory and
>  >>>> getting it wrong (which year? trailing slash?) would waste even
>  >>>> more time.
>  >>>
>  >>> I fail to see how this is a problem. Is copy & paste too hard?
>  >> Yes, when the plausible alternative is not having to do that.
>  >
>  > Well, short names require a central registry.
>
>
> A central registry is a good thing in order to avoid a Babel of
>  languages with no coherent common feature set for authors to rely on.
>
>
>  > Doesn't scale as well as URIs. See the related microformats
>  > discussions.
>
>
> http://www.w3.org/TR/ seems to scale well enough to cover HTML, SVG
>  and MathML.
>
>
>  --
>  Henri Sivonen
>  hsivonen@iki.fi
>  http://hsivonen.iki.fi/
>
>
>

Received on Tuesday, 11 March 2008 15:14:23 UTC