W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > July 2006

RE: ISSUE-12 identifying conformant schemas

From: <paul.downey@bt.com>
Date: Mon, 17 Jul 2006 00:17:14 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC95225504BFEBA2@I2KM11-UKBR.domain1.systemhost.net>
To: <gcowe@origoservices.com>, <public-xsd-databinding@w3.org>

Thanks George, this is really useful work..

and sorry not to get back sooner..

> 1) use the "one schematron pattern per schema pattern" 
> approach which seems to work best.

I think it does, in fact I think one XPath per pattern is best.

> 2) just use one schematron pattern with one rule (context of root)
> and multiple reports/asserts. This behaves in the same way as the 
> "one schematron 
> pattern per schema pattern" approach but only reports/asserts the first 
> occurrence of a schema pattern. Which means you don't get information 
> about the individual complexType/simpleType/element which is firing the rule.

> 3) just use one schematron pattern with multiple rules (one for each schema pattern). 
> The problem here is that only the first rule matched is fired so it's 
> pretty useless! This also seems to be the only sensible way to use the 
> catch all @*|* rule unless I'm mistaken.

Right, so AIUI approach (1) is best for detecting the known patterns
in a schema and (3) is the only way to make the catchall work.

> This simply allows a list of patterns that have been detected to be listed. 
> What we really want is a list of patterns that are detected as not 
> being present in the basic patterns and highlight these as an issue. 
> How do you do that without actually looking specifically for them?

OK, I'm happy for us to have 'anti-patterns' which we mark as 'advanced'
or maybe 'pending' or 'other' but we still need a catch-all
given you have to look for unknown stuff regardless, no? 

To help move this on I've thrown together a basic patterns.xml file:


which is used to generate a (1) style schematron schema:


then ran this against all our example schemas, generating
a patterns.txt file for each example:

I think we can use this to generate a per-schema type (3) 
schematron schema which looks for only known patterns 
for that schama and bounces 'other' stuff, 
OTOH if you want a schema to only contain basic patterns
and we flag known 'advanced' or 'pending' patterns,
well you can probably skip the second pass ...

My concern now is the granularity of the patterns - I've
not gone deeper than 'element of type xs:string' or
elementFormDefault .. 

Received on Sunday, 16 July 2006 23:17:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:56 UTC