W3C home > Mailing lists > Public > public-xml-er@w3.org > February 2012

RE: Draft - Fixup or Full XML Parser

From: David Lee <David.Lee@marklogic.com>
Date: Tue, 21 Feb 2012 14:37:23 -0800
To: Norman Walsh <ndw@nwalsh.com>, W3C XML-ER Community Group <public-xml-er@w3.org>
Message-ID: <EB42045A1F00224E93B82E949EC6675E16ADC5FA52@EXCHG-BE.marklogic.com>
Your missing my point, or perhaps I'm insane.
I'm not saying that an implementer could not choose to combine an "ER Parser" and an "XML Parser" and to good effect.
What I'm suggesting is that we don't mandate it, and therefore avoid a huge big of work by having to require it.
I have yet to hear an argument as to why we must spec an "ER Parser" to by mandate to a full "XML Parser".
In fact I have yet to hear one case why its even useful to spec it as a *requirement*.

But again, not to say an implementation  wouldn't likely choose to combine the too.
But it's a HUGE step as far as I can see going from "It seems to me ... it could just ..."  to saying "All EHR Parsers MUST" ...




	


David Lee <David.Lee@marklogic.com> writes:
> Norm, what's your opinion on the use case of using an ER parser as a 
> front-end to an existing parser.
> To me that seems the simplest and most useful case. (although almost 
> certainly not the most *efficient*).

It seems to me that by the time the ER parser has figured out how to do the fixup, it could just generate the tree more easily than turning it back into characters for a second parser to read.

                                        Be seeing you,
                                          norm

--
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com
Received on Wednesday, 22 February 2012 12:57:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 12:57:49 GMT