RE: Two Specs and Test Suite

We can probably borrow from others for this.  I know the XProc group has a framework
I use a framework for testing xmlsh (makes use of http://www.xmlsh.org/CommandXcmp ) and there are others.   I think we could rely on the existence of text based XML compare tools which compare equivalent documents without having to dig too deeply.

-----------------------------------------------------------------------------
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 3:43 PM
> To: Robin Berjon
> Cc: Jeni Tennison; W3C XML-ER Community Group
> Subject: Re: Two Specs and Test Suite
> 
> 
> 
> On 2/27/2012 3:24 PM, Robin Berjon wrote:
> > On Feb 27, 2012, at 21:09 , Jeni Tennison wrote:
> >> >  Therefore, I propose that we do both. Further, I'm happy to edit the
> declarative-style specification unless there's someone else who wants to do
> it. Are there any objections to that as a way forward?
> > +1!
> >
> >> >  We will also need a test suite, and it sounds as if one that is based on
> the XML result of an ER parse would be easiest to manage and most
> generally useful. Does anyone have any suggestions about how best to
> manage and maintain one?
> > I think that the hard part in testing this is to do so in a manner that is
> friendly to both browser and batch environments. In the former, the easiest
> is to run assertions against the DOM that's produced, but in the latter it's
> likely to produce some form of canonical version (which doesn't have to be
> C14N - for instance PYX has historically been great for testing) or use some
> form of XML diff facility.
> >
> > I don't think that there are any in-browser XML diff facilities, and it's not
> clear that there's a reliable XML serialiser we could use there. The simplest
> might therefore be to use PYX-based reference interpretations and those
> could be compared in either situation. But that's just one way that it could
> work and is entirely based on what I assume implementers will find most
> useful.
> 
> It occurs to me that, at least for testing purposes, the XML
> Canonicalization specification [1] may be a useful building block. I
> suspect one might have to add a few rules beyond what it standardizes, but
> if you serialize two DOMs and then canonicalize, you're probably pretty far
> along toward having strings that can be compared character-for-character.
> Of course, if we decide to specify XML-ER at the source level after all,
> then one can skip the serialization step, and for texting just use
> C14N(suitably enhanced) and string compare.
> 
> Just a thought.
> 
> Noah
> 
> 
> [1] http://www.w3.org/TR/xml-c14n

Received on Monday, 27 February 2012 20:47:05 UTC