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.
Regards
Rick
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?Thanks,Tom