FW: [xml-dev] MicroXML

All,

I'm forwarding this e-mail to the Forms Working Group as input into our discussion this week on future changes/branches in XML and how it might affect XForms.

MicroXML, as a subset of XML, doesn't look like an immediate problem to XForms. James' comment:

If you are doing XPath 1.0 specifically for MicroXML, you might want to build the XPath data model a bit differently from usual (ie treat "xmlns" as an attribute), but that's allowed by XPath.

would have to be considered. As for the rest, it does seem a workable solution to lightening XML.


Regards

Philip Fennell
Consultant
MarkLogic Corporation




From: James Clark [mailto:jjc@jclark.com]
Sent: 13 December, 2010 2:05 PM
To: Philip Fennell
Cc: Dave Pawson; xml-dev
Subject: Re: [xml-dev] MicroXML

On Mon, Dec 13, 2010 at 8:51 PM, Philip Fennell <Philip.Fennell@marklogic.com<mailto:Philip.Fennell@marklogic.com>> wrote:
Unless I've missed something, there's nothing here that would prevent MicroXML from being embedded 'in-line' in XML 1.0 is there?

Right, it's a subset.


I do a fair bit of work with XForms and XProc, not to mention XSLT, so the things that I'd see as important are:

1) Can I embed fragments of MicroXML in an xforms:instance, an xproc:inline or an xsl:template?

Yes.

2) Can I traverse the structure using XPath?

Yes.  If you are doing XPath 1.0 specifically for MicroXML, you might want to build the XPath data model a bit differently from usual (ie treat "xmlns" as an attribute), but that's allowed by XPath.

3) Would my XForms, XProc or XSLT processor need a specific serialisation mode?

There's the issue that empty elements are not equivalent to a start-tag followed by an end-tag in HTML5. In the context of XSLT, it's probably best to solve this with an HTML5 output mode.

Beyond those questions, from what I've seen so far, I can think of no reason not to use MicroXML as a light-weight data format but I'd imagine I'll still be using XML 1.0 + Namespaces for XForms, XProc and XSLT.

I would expect so.

After all, it's the data that's more the problem than the XML languages we process it with, right?

Yes, it's always good to have data in a maximally simple and constrained format.

James