RE: Draft - Fixup or Full XML Parser

It *may* (or may not)  make the parser simpler as it could avoid doing some things that XML parsers MUST do like external entity inclusion.

It would absolutely make the *specification* simpler because we can only spec out the parts that XML-ER actually needs.  And considering what we're proposing in this group is a specification not an implementation I suggest that is what we should focus on.
The product of this group is a specification, thus anything  that can be done to make the specification simpler, IMHO, is something to be strived for - whether or not it means the implementation is simpler.

-----------------------------------------------------------------------------
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: innovimax@gmail.com [mailto:innovimax@gmail.com] On Behalf Of
> Innovimax W3C
> Sent: Tuesday, February 21, 2012 11:07 AM
> To: Shane McCarron
> Cc: public-xml-er@w3.org
> Subject: Re: Draft - Fixup or Full XML Parser
> 
> I can't see how having this pre-verification step would make the
> XML-ER parser simpler ?
> 
> Mohamed
> 
> On Tue, Feb 21, 2012 at 4:48 PM, Shane McCarron <shane@aptest.com>
> wrote:
> >
> >
> > 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
> >
> >
> 
> 
> 
> --
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 9 52 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr

> RCS Paris 488.018.631
> SARL au capital de 10.000 €

Received on Wednesday, 22 February 2012 12:57:06 UTC