On Jun 19, 2006, at 17:37, Hugh Wallis wrote:
> Specifically the questions I seek input on are as follows:
>
> 1) Should implementers of specifications that do not provide  
> normative schemas for the namespaces they define confine themselves  
> rigorously to those things that are explicitly defined by the  
> specification in question

That would certainly strike me as a best practice. Are there cases in  
which this would not work? Also, I would expect that it should be  
possible to produce one schema document that only has strictly what  
is in the specification, and another that includes it to add some  
sugar, e.g. attribute groups. Of course, that still leaves any amount  
of leeway for incompatibility between schemata for the given  
namespace, as well as misinterpretations.

> 2) Should specification authors provide NORMATIVE schemas for any  
> namespaces that their specifications define so as to avoid any  
> possibility of incompatible/non-interoperable implementations  
> resulting.

I think that any W3C WG that produces a vocabulary for XML RFC-2119- 
SHOULD produce a normative schema for that namespace. This is  
generally considered good practice but AFAIK is not enforced by the  
publication process (I don't remember it being mentioned by the QA  
guidelines either, though I might be forgetting).

The problem with the above is that it is all nice and well but it  
does not address the nest of snakes of which schema language to use,  
and of whether an XML Schema version should be produced. On the one  
hand it won't help your problem much if you're using XML Schema and  
the WG in question only has a RelaxNG schema, on the other hand I  
would expect much screaming to follow if any single schema language  
were enforced. Conversion is appealing, but the EXI WG's quick  
investigations in that area tend to show that there doesn't seem to  
currently be a tool that can automate schema conversions while  
guaranteeing that the output schema is correct.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/



From xmlschema@s... Mon Jun 19 16:40:39 2006
Received: fr