Re: Intent of ER-XML

On 2/27/2012 4:05 PM, Robin Berjon wrote:
>> The current draft doesn't really do anything (much) towards specifying
>> a
>>> processor (even one using a DOM AI) Nothing about how the nput is
>>> fed in, or how the results and.or errors are fed back out.
> Exactly, it only uses the DOM as a concrete definition of the data model
> that is used to interpret the document from the token stream. That's why
> I'm having trouble seeing what we gain from dropping that.


FWIW, I never argued for dropping it. Some have asserted that what we need
is a specification for a "processor", e.g. so that one can be a drop in
replacement for another, and that makes me nervous. Using a DOM or DOM 
subset as a documentation convention for the abstract tree seems
OK to me, as long as we make clear that code implementing the tree using 
other APIs is equally conformant.

David Carlisle wrote:

> the point is to have a well-defined common understanding of what an
> element, attribute, etc. are. The fact that it maps onto something that
> one can immediately implement is, I find, very helpful in making it
> concrete.

Well, at the very least, it's certainly helpful to the many implementors 
who will in fact be using the DOM.

Maybe we're all not that as far apart in our positions overall as
the tone of this thread might suggest? It's the "spec for a drop in 
replacement processor" goal that would make me nervous. Thanks.

Noah

Received on Monday, 27 February 2012 21:34:04 UTC