Re: XML namespaces on the Web

> The issue is that there are other applications and use cases beyond HTML 
> for which a sensible, general purpose, interoperable, non-draconian 
> model is more appropriate than what we currently have with XML (Notably, 
> RSS/Atom feeds).
If you use a feed to e.g. remotely control an army, probably you'd rather have it strictly parsed (I certainly would, but I would, and actually do, also for casual HTML authoring, so don't look at me to determine the other end of the spectrum). The complexity and sensitivity of tag soup parsing make it a toy language suitable for toy use cases only. Why should we force HTML and feeds into this category and block the way out?
That's also why I want a switch (whose absence, which should be prevalent, will let the processor decide).

> HTML parsing does not address these cases because, due 
> to legacy constraints, it doesn't provide sensible, generable purpose 
> parsing.
+∞

Jirka Kosek wrote:
> If you think that there
> should be unified error handling for XHTML content, solution is very
> simple -- just take respective parts from XML5 proposal and add them to
> HTML5 and say that if UA finds well-formdness error in XHTML content and
> it wants to recover from it it must use this specific recovery
> algorithm. And you are done and it is not necessary to change single
> character in the current XML spec.
It's a general problem, likely to occur elsewhere (apparently the situation with feeds is going in that direction). XML is the right level to deal with it.

Liam Quin wrote:
> We have *excellent* interoperability in most of the XML world.
> Of course, "most" is a hard term to define -- RSS represents a
> small fraction of total XML in the world if you include Web
> services and xml-rpc, for example...
How about HTML? The architectural vision of the W3C is to integrate it with the XML world. Currently it's debatable whether it's even some form of SGML (definitely not the one from the HTML 4.01 spec). We have both more that one instance of the problem (HTML and feeds) and one which is huge (HTML).

> The XML5 proposal would not make the current XML 1.x parsers 
> non-conforming.  Aborting on fatal errors will still remain a conforming 
> option for applications.  All XML5 does is fill in the gap where it's 
> missing from XML 1.x.  Namely, what to do if the application chooses not 
> to abort by defining clear recovery procedures.
>
> Thus, any kind of flag from the author is completely unnecessary and 
> only serves to create backwards compatibility problems where there need 
> not be any.
Then what you want isn't XML5 (or 1.2, or whatever) but either new editions of XML 1.0 and 1.1 or a new RFC for XML MIME types specyfying the recovery. I suppose XML specs would be better places. It's orthogonal whether the MIME parameter is added, but I've already given rationale for it. Also, I think it's premature for this group to say that a genuinely new version of XML is or isn't needed.
 The XML Core WG should make their call first. I believe it is needed. XML 1.2 could be still parsed by 1.0 parsers [1] (see also [2]) and I expect 1.1 to be aligned on this. It seems desirable for instance because of integrating the Infoset (having multiple syntaxes calls for some abstraction for other specs, and the tag soup wouldn't be the only additional one, for there's EXI - anybody knows what ascribes graphical semantics to an SVG document encoded as EXI when the SVG spec says SVG is a dialect of XML, meaning a profile of SGML, not some binary stuff, or soup?). Other issues could be fixed as well (splitting out DTDs, bringing in namespaces, xml:id, XML Base, following Anne van Kesteren's spec in converting CDATA sections to text on parsing…).
> create backwards compatibility problems where there need
> not be any
Well, backward and forward compatibility are always concerns to some degree when transitioning to a new version. Let's leave that to the XML Core WG to decide if now is the right time.

Best regards,

Krzysztof Maczyński

[1] http://www.w3.org/TR/REC-xml/#NT-VersionNum
[2] http://bugzilla.mozilla.org/show_bug.cgi?id=500139

Received on Tuesday, 17 November 2009 22:38:13 UTC