OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Ensuring samples are representative

For Feature Grammars, the problem is not recursion in the document grammar (such as p allowing a p desvendent) it is recursion in the feature grammar, which can be avoided (I.e. if you can order all the features in the schema  top-down so that each feature's grammar never specifies a feature that was defined before it was used, then there is no recursion.)

If unable to grok,  use Schematron @flag for same purpose. I have worked for several years on Xml conversion projects where we tested the conversion with Schematron: one approach we usef for XBRL testing  was to actually write a reverse of the transformation: so we can compare the round-tripped document with the original.


On 18/10/2016 8:34 AM, "yamahito" <yamahito@gmail.com> wrote:
Hi Folks,

I have an upcoming contract that will involve converting between XML formats.  My client wants their customer to provide a representative sample to contract against (i.e. when the transform works on the sample, our work on the contract is fulfilled).

The onus may be firmly on the end customer, but I want to get as much right the first time as possible, and I think they can be helped to ensure that the sample is representative.

What would people recommend to help a) ensure that the sample *is* representative and b) help target/prioritise the work on the transformation?

My initial thoughts would be to use Trang or similar to generate schema from both the sample set and the full data set (if possible: it's likely to be very large), but I'm worried that it will be hard to identify something meaningful.  I've also come across tools that offer some form of statistical 'analysis' of XML data sets;  I was interested in Rick's Feature Grammar tool but I don't claim to understand it (yet), nor be sure that there won't be recursive features in the data (I would be surprised if there weren't).

I'm interested in how others approach the problem - any ideas?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS