RE: Intent of ER-XML

I'm +100 with Noah. 
If the primary purpose of defining to an API is for testability I think that makes this very hard. 
Its much easier to compare and test text then API behaviour. 
So we could define testability by a statement like "If the results of the XML-EHR processing model are serialized via the XML Text Serialization Specification they should look like this: ... "
Then test case *in Text* could be produced and tested against using the plephra of XML diff/compare tools.    I think this is vastly easier than trying to test the results of say 2 DOM processors via API specs.
  


-----------------------------------------------------------------------------
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: Noah Mendelsohn [mailto:nrm@arcanedomain.com]
> Sent: Monday, February 27, 2012 12:52 PM
> To: Robin Berjon
> Cc: public-xml-er@w3.org
> Subject: Re: Intent of ER-XML
> 
> 
> 
> On 2/27/2012 12:31 PM, Robin Berjon wrote:
> > My understanding, and please tell me if I'm wrong, is that your use case
> > is to make it possible to have more than one API/interface based on the
> > same core specification.
> 
> That is an important use case, yes.
> 
> > If that's correct, what I'm saying is that we can build the
> > specification to one API, and *still* make it possible (and efficient,
> > useful, etc.) to have other APIs (or more broadly interfaces) layered on
> > top of it. And not only will it be possible, but it will be easier to
> > specify and test, and more conducive to alternative processors that can
> > interoperate properly.
> 
> I understand where you're coming from. I think we'll have to agree to
> disagree on what's best in this case. My concern is only partly to support
> the use case, though that's important; it's my feeling based on experience
> and intuition is that it's generally best to not mix a specification for a
> language with a specification for a processor for that language. When you
> do mix that way, you tend to wind up specifying as standard many details
> that weren't really core to your intent for the general case.
> 
> Given that you propose to document one API, would you also include rules
> for determining whether some other API is or isn't conforming, or would you
> limit the conformance terminology to processors that implement exactly
> that
> API?
> 
> Thanks.

Received on Monday, 27 February 2012 18:17:40 UTC