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

RE: Intent of ER-XML

From: David Lee <David.Lee@marklogic.com>
Date: Sun, 26 Feb 2012 17:46:09 -0800
To: David Carlisle <davidc@nag.co.uk>
CC: "public-xml-er@w3.org" <public-xml-er@w3.org>
Message-ID: <EB42045A1F00224E93B82E949EC6675E16ADCEEEE8@EXCHG-BE.marklogic.com>
> >
> > But how do we solve this magical goal of a 'drop in replacement' for
> > an XML parser ? I suggest it is impractical to do this by defining a
> > "Processor". But rather by defining the abstract rules (in whatever
> > meta-language or model you like). This still doesn't give us a 'drop
> > in' replacement for an XML Processor, but what it does give us is
> Not sure I understand this point. The XML spec is pretty vague about
> what a processor is (and certainly almost silent about how it reports
> things). If the xml-er is similarly vague then it can be a drop-in
> replacement for an xml parser in the same way as one xml parser may (or
> may not, depending) be a drop in for another.

This is an interesting perspective, one I had not considered.
On the one hand I agree completely, but on the other it seems like it contains very little information ; making a hard statement about something based mainly on its absence of definition.  
But on the other other hand, that may be the solution to the conundrum - make the specs intentionally vague.   Omission can be a very positive thing as long as what is omitted is not something intended to be tested.

> >
> > A) A consistent statement of how an XML Processor can support
> > "XML-ER"
> Not sure I understand that. presumably an XML processor as defined in
> xml 1.x can't support XML-ER rules?

Arg ! Got me !
A processor cannot simultaneously be a XML 1.x AND a XML-ER processor at the same time.
Which means they are definitively different things.  An XML-ER processor ("parser"?) cannot be an XML 1.x parser ... at least at the same time.   An implementation could provide both but not simultaneously.

Hence the intent or meaning of "drop in" is hard to define ...

> But the thing it did need is a new parser. The fact that code generation
> etc could be re-used is more akin to the fact that (if we spec it right)
> the existing tool chain such as validators and xpath etc should all be
> able to work with an XML-ER parser.

Yes good point.
But where do we draw the line between parser and "toolchain" ...
For example where do things like DTD's , XInclude, external entities come in ... 
I could see several opportunities.
E.g. should XInclude or external entities also invoke the XML-ER processor ? 
Should that be defined by the spec or left up to implementers ?

> I'm not sure I understand well enough how you intend this to work to be
> able to agree or disagree. If you view the DOM references in the current
> draft as a description of an abstract tree type rather than tied to a
> particular API, does the current spec meet this description, or do you
> mean something else?

I have little problems with the spec as-is as a start.  My discussion is more a step-back to discuss how to go forward and to do that we need an agreement on the "philosophy"... that is what are we trying to describe ?   Without that being clear I can't even analyze the spec in more detail to have an opinion. 

David Lee
Lead Engineer
MarkLogic Corporation
Phone: +1 650-287-2531
Cell:  +1 812-630-7622

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.

Received on Monday, 27 February 2012 01:46:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:26 UTC