Re: Why MicroXML ?

--- John Cowan <cowan@mercury.ccil.org> schrieb am Di, 24.7.2012:

> > I think a steamlined description along a simple
> > standard way and pushing all special cases into
> > an apendix might work. I would love to stand
> > corrected, but I can't realy find a lot in the
> > XML specs to be thrown out or what could be
> > simplified by reduced definitions. The way how
> > we teach XML could make the difference we are
> > looking for.

> I am not sure I follow you, but if you compare my Editor's
> Draft with the XML Rec plus the Namespace, Infoset, xml:id,
> and xml:base Recs, you'll see just how much smaller it is:
> 68 pages vs. 9 pages.

Size may be one measurement _after_ a good work is dine, but not to start with. Remember how people put whole processor programming manuals onto a little 1 page leaflat? Everything was on, but you had to have already most knowledge about the CPU to understand it.

Every document, intended to educate a new reader, MUST itell first what the spec within is good for and sometimes (like with XML) what not. I apreciate the work you did, but I'm not realy clear what you want to acomplish with it. Let me just pick some examples:

#1 Section 2.1 Definition 1

[1] document ::= comments (doctype comments)? element comments

allows comments to be placed ahead of an (optional) doctype declaration (*1). While XML defines a document as something that begins with an (optional) XML declaration

[22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?

Of course, since the XML declaration is basicly a PI, it would still be possible to have the XML declaration as very first PI. If a document creator adds comments (comment/PI/S) before the XML declaration, it's screwed up. Thus a document can be well formated MicroXML but no longer XML - wouldn't that break te goal to make a usable subset?

*1 - It would be cool to use the same terminology than the existing XML spec, at least for now. this avoids missinterpretation when comparing. New names should only be used for new constructs)


#2 Section 2.2 Elements states

"For compatibility, an empty element whose name is br SHOULD be expressed with an empty-element tag".

The first question that poped up in my head was 'What the heck does an element definition in XML?' XML does not define Elements nor does it handle elements of any kind. Thats something XML applications does. And, unless thers a generalized way to so so (*2), handling such quirky behaviour CAN NOT be part of an XML subset. It'll not only break XML compatibility, it also breaks the whole XML idea of defining a way to define data exchange struktures.

*2 - if we want to make a standard way to define elements that can be empty but do not have to carry the '/' we need to extend the syntax of DTD definitions (of course this may break XML parsers using the DTD for validation)

#3 Now, looking back at section 1 (Introduction) there is a list with statements wher two realy catched my eye. The first was

"Many specifications that support XML are in fact already using their own ad-hoc subsets of XML (eg XMPP, SOAP, E4X, Scala)"

and

"With properly chosen elements and attributes, MicroXML documents can also be valid HTML5, which is not the case for XML documents in general"

read with your reply

> [...] but if you compare my Editor's
> Draft with the XML Rec plus the Namespace, Infoset, xml:id,
> and xml:base Recs, you'll see [...]

in mind, it makes me wonder if we realy talk about a simplified XML. To me this yells Micro-X-HTML

XML-ID, SOAP, HTML are XML _applications_ they are not XML nor part of it, they are data formats that USE the mechanisms described in XML as thir method of structuring element detection. They are no subset (as stated) but a superset (more than) of XML. They _use_ XML to format meaningful content(structure).

So is the goal here to create some (extensible) application language or a simplified XML?

If we are about to do a simplified XML _and_ want to keep it compatible, then there is, by logic, only one way to so so: The spec MUST be a subset of XML and only XML. Otherwise, if MicroXML is (in parts) a superset, a standard abiding XML Parser will reject MicroXML documents.

Serious, we need to define the target we are working on in a way free from assumptions.

H.
--

www.vcfe.org

Received on Wednesday, 25 July 2012 11:29:45 UTC