RE: Draft - Fixup or Full XML Parser

I think that would be a perfectly valid use case. 
But I might want to do this 

if ( option to tidy ) 
     xml-er | xml-parser | app
else
   xml-parser | app 

That way as an implementer I could *choose* to write a (presumably much simpler)  xml-er program to do JUST the fixit part and not have to touch my already working "xml-parser" which may well be from a third party which has decided to ignore our great work but who's XML parsing stuff I want to use.

As a spec writer, should we *insist* that the xml-er is a superset of xml-parser ?  To what benefit is that ? and what cost ?

I personally see negative benefit and high cost. 
Negative benefit as it forces a smaller set of use cases available to implementers.
High cost as it means we must *in addition* to the ER part ALSO implement 100% of the XML parser spec.

Assuming that an implementer *could choose* to implement xml-er as part of a XML parser , to me it seems
higher  benefit and lower cost by decoupling those at the spec level with no disadvantages to an implementer if they chose to combine them.


-----------------------------------------------------------------------------
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: Shane McCarron [mailto:shane@aptest.com]
> Sent: Tuesday, February 21, 2012 10:48 AM
> To: public-xml-er@w3.org
> Subject: Re: Draft - Fixup or Full XML Parser
> 
> 
> 
> On 2/21/2012 9:19 AM, Anne van Kesteren wrote:
> > On Tue, 21 Feb 2012 14:16:48 +0100, David Lee
> > <David.Lee@marklogic.com> wrote:
> >> My personal opinion is that the XML ER should be speced as the fixup
> >> parser only and not presume that it is a full XML parser.  I think
> >> this will save us a lot of work, and provide more value.
> >> Comments ?  Objections ? Am I passed left field ?
> >
> > How would you envision this "fixup" to work? What you describe sounds
> > like 1. determine whether it needs fixup; 2. fixup; 3. parse. The
> > alternate approach is just parse, which seems somewhat more
> > straightforward.
> >
> 
> I envision this (in one type of environment) as an element of a toolchain:
> 
> XML Parser ---> Tools that deal with well formed XML
>         |                               ^
>         V                              |
> XML-ER Parser ---------
> 
> So in my world I would try to use a traditional (and therefore speedy)
> XML parser.  If that failed, failover to XML-ER where it would fix-up
> the input and what comes out would be tool-chain ready.
> 
> Maybe I am now guilty of presupposing a solution...
> 
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
> +1 763 786 8160 x120
>

Received on Wednesday, 22 February 2012 12:56:43 UTC