RE: tag name state

To help me understand. 
Could you describe exactly what you mean by "output a DOM"

Thanks

-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 650-287-2531
Cell:  +1 812-630-7622
www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

> -----Original Message-----
> From: Robin Berjon [mailto:robin@berjon.com]
> Sent: Sunday, March 04, 2012 1:44 PM
> To: Noah Mendelsohn
> Cc: public-xml-er@w3.org Community Group
> Subject: Re: tag name state
> 
> On Mar 3, 2012, at 04:04 , Noah Mendelsohn wrote:
> > What I am suggesting we consider is a model that builds on the XML
> Recommendation, since that's what we're trying to "fix up to".
> 
> I don't believe that this is the primary goal however.
> 
> The first and foremost use case that prompted this work was the ability to
> use XML in user-facing scenarios in such a manner that users are not the
> ones being punished for WF errors. The fact that users get a terrible
> experience whenever there's a WF error makes XML nothing short of a
> terrible format for user-facing content. It would be helpful to fix that.
> 
> But all that that requires is parsing into a DOM. It does not require the
> ability to serialise to XML, and it does not require compatibility with the XML
> DM.
> 
> That is not to say that the two latter are not important, or useful. They're
> actually pretty nice things to have around.  But, to say this yet again, it
> would be most useful to have access to the two latter *also* when the input
> is not XML but anything else that produces a DOM - especially if it is HTML.
> 
> The only viable manner of addressing the latter case is with a DOM to XML
> conversion algorithm. Assuming we have that, all that XML-ER needs to do is
> output a DOM, which can then be converted.
> 
> This has advantages that none of the alternatives have:
> 
>     * We already have a lot of the specification work done.
>     * It takes the "HTML at the front of an XML pipeline" case into account.
>     * It uses the DOM, which is the simplest and loosest model.
>     * It is more user(-agent)-friendly.
> 
> In general it also seems (to me) a lot closer to the sort of things that people
> in the HTML/XML TF or at XML Prague have indicated they were interested
> in doing.
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
> 
> Coming up soon: I'm teaching a W3C online course on Mobile Web Apps
> http://www.w3devcampus.com/writing-great-web-applications-for-mobile/
>

Received on Sunday, 4 March 2012 19:09:04 UTC