It’s just data

MicroXML vs XLink

James Clark: Relative to XML, my objectives for MicroXML are:

  1. Compatible: any well-formed MicroXML document should be a well-formed XML document.
  2. Simpler and easier: easier to understand, easier to learn, easier to remember, easier to generate, easier to parse.
  3. HTML5-friendly, thus easing the creation of documents that are simultaneously valid HTML5 and well-formed XML.

This page, like most pages on my web site, is valid HTML5 and well-formed XML.  This page also happens to conform to MicroXML.  I can’t make that statement in general about pages on my site, as I do make infrequent use of xlink attributes (page down a bit in the attribute syntax section of the HTML5 spec).

More generally, unless xlink becomes grandfathered in somehow, MicroXML is not sufficient for SVG.

There is a good chance that XLink won’t be required in SVG 2. (Which complicates things a little, if you might have both xlink:href and href on the same element, but it’s probably worth it to simplify the language for authors.)

That doesn’t affect the compatibility of MicroXML with currently deployed SVG content though, obviously.

Posted by Cameron McCormack at

I suspect that XLink will likely die a quiet death after an interesting if not entirely successful life. It’s support in SVG was always something of an oddity.

My suspicion is that namespaces overall will end up disappearing due to HTML5 for any of the XML technology in the browser - XForms has its own namespace, the ev: namespace of xml-events and the xs: schema namespace that provides complications, not to mention the need of binding a namespace to an xf:instance content. SVG would lose its own namespace and that of xlink.

Is this a bad thing? Conceptually, perhaps. Pragmatically, no, not really. It makes XSLT a problem case (though not a critical one, as few people did extensive client side manipulation of XSLT doms), but strengthens the argument for XQuery, which I think has an easier syntax for web developers to utilize. Perhaps it pushes the idea of umbrella namespaces on the XML side one step closer.

Posted by Kurt Cagle at

I suspect that XLink will likely die a quiet death

That may be well and good, and perhaps HTML6 will reflect that.  Meanwhile, MicroXML falls short of its goal of being HTML5-friendly.  Either that, or people need to get busy and start submitting bugs against HTML5.

Posted by Sam Ruby at

This is a known problem.

My first proposal for MicroXML had a more complex approach to namespaces that would have allowed this. The big disadvantage of this was that MicroXML documents would not be guaranteed namespace well-formed.  The choice between these two approaches is not obvious to me.

HTML5 already does some fixup up on embedded SVG markup to make things easier for authors (eg fixing the case of tag names and attribute names). Would it make any sense for HTML5 to allow people to omit the “xlink:” prefix on some SVG attributes and to add it as part of tree-building? That would be consistent with HTML5’s general avoidance of namespaces and would make things easier for authors.

Posted by James Clark at

Would it make any sense for HTML5 to allow people to omit the “xlink:” prefix on some SVG attributes and to add it as part of tree-building?

Perhaps.  I encourage you to participate.  Speaking as one of the co-chairs of the group, I can assure you that your input would be welcome.

Posted by Sam Ruby at

OK - I got a huge questions here regarding SVG. I have dissected this posting site regarding your SVG images. I was having problems getting any inline SVG to work with Safari. If I went to your site via Safari your SVG tags would work. If I copy and pasted the SVG into my dev envirmoment (MS MVC2 rendering to HTML5) your SVG tags would not rendered. This drove me crazy. So then I completely copied and pasted your entire source, changed the links to pull the CSS in and the JS, thinking it is exactly identical it will work. NOTHING. Everything looked pretty as before but no SVG inline rendering. So then I went to Chrome - bang - rendered perfect - went to Firefox - NOT rendering - went back to Safari - NOT rendering - went back to Chrome - rendering - MSIE is not an issue as it is not wide spread compliant - . . . can you give me guidance on why it would render fine if pulled directly from your site - but once copied and pasted it only renders in Chrome but not Safari . . .

Appreciate it -


Posted by MOKANA at

MOKANA: the difference is the MIME type.  I serve my content as application/xhtml+xml to user agents that indicate that they accept this MIME type.

Newer browsers, including IE9 and Firefox 4, will support inline SVG in content served as text/html.

Posted by Sam Ruby at

two simple ways:

1. Over HTTP, you must serve the resource as application/xhtml+xml
2. On filesystem, name your file “.xhtml”

Posted by karl at

Same exact thing here!
WebKit Nightly does NOT have this problem, so it’s been fixed for a future version of Safari.

But that does NOT help you for iOS users (iPad iPhone etc) — but it works for Safari 5 Mac, iPad iPhone 4 even original “2G” iPhone if the MIME type is set correctly.

For my Mac’s Apache web server on OS X 10.6, I added a single Apache config file; copy these lines to /etc/apache2/other/rewrite-xhtml.conf:

<IfModule rewrite_module>
	RewriteEngine on
	RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
	RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
	RewriteCond %{REQUEST_URI} \.html$
	RewriteCond %{THE_REQUEST} HTTP/1\.1
	RewriteRule .* - [T=application/xhtml+xml]

Then issue this command
sudo apachectl restart

and your pages will work without renaming them to “.xhtml”. The browser will tell the server that it prefers the XHTML version, and it will get the (same) file served with the correct MIME type.

Of course, to play along, you should write your HTML so that it works as HTML5 and XML:
Polyglot HTML

Posted by Boyd Waters at

The version of MicroXML I’m pushing allows prefixes in attributes but not in elements, so xlink can be specified.  Namespace declarations don’t affect the object model, so there’s no problem if a prefix is not declared.

Posted by John Cowan at

Namespace declarations don’t affect the object model

So, if one were to parse, say, this web page... what namespace would the svg element be in?

Posted by Sam Ruby at

It would be in the SVG namespace.  But if you moved a path element somewhere else in the document, it would now be in the HTML namespace, unless you were careful to carry along the namespace declaration.  You can’t push the declaration to the root and then use elements named svg:path.

Posted by John Cowan at

Add your comment