RE: Draft - Fixup or Full XML Parser

Does your definition of "tool chain" include an XML parser or not ?
If so, then my reading  of your diagram is that it does NOT leave your "tool chain" alone.
If not, then the XML-EHR parser would be a drop-in replacement for "XML Parser" in your diagram.
But what if you wanted some special fancy things in your "XML Parser" that are implementation specific, say for example StAX events, or schema aware XSVI data ?    Then this diagram means that implementers need to  re-implement every variant of XML parser out there.
Thats why I suggest that from a specification point of view, that the "XML-ER" part not be presumed as necessarily being a drop in replacement for an XML parser, but rather a set of abstract rules which might be implemented as a front end or integrated into an existing parser or whatever you want.



-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 650-287-2531
Cell:  +1 812-630-7622
www.marklogic.com<http://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.

From: Shane McCarron [mailto:shane@aptest.com]
Sent: Tuesday, February 21, 2012 11:21 AM
To: Innovimax W3C
Cc: public-xml-er@w3.org
Subject: Re: Draft - Fixup or Full XML Parser

It wouldn't. It would leave my existing and working toolchain alone, augmenting it with a fixup tool for when things are broken.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Innovimax W3C <innovimax+w3c@gmail.com> wrote:

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 fix!



 up; 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 €