Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Creating schemas for other people's namespaces - what can you do and what can't you do?

From: "Hugh Wallis" <xmlschema@------------------.--->
To: "'Robin Berjon'" <robin.berjon@------.-->
Date: 6/19/2006 8:40:00 AM
Thanks for your input Robin.

It would seem appropriate to me that a W3C WG should at least provide a
normative schema using a W3C standard (like XML Schema). I would have no
problems if they were to provide other normative schemas using other schema
languages as well - bearing in mind that different languages are capable of
expressing different things (like co-ocurrence constraints for example).

The problem with the sugary schema suggestion is exactly the issue I
described in detail below - you are almost guaranteed to end up with
incompatibilities between implementations I think.

I suppose I could have worded my first question differently i.e. "Do
implementers of specifications that do not provide normative schemas for the
namespaces they define have the right to include anything that is not
rigorously defined by the specification in question?" - it seems to me that
really they don't because they don't "own" the namespace - but there are
others who think differently so I am very interested to get a broad set of
opinions on this.

Thanks

Hugh

-----Original Message-----
From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] On
Behalf Of Robin Berjon
Sent: Monday, June 19, 2006 12:12 PM
To: Hugh Wallis
Cc: xmlschema-dev@w...
Subject: Re: Creating schemas for other people's namespaces - what can you
do and what can't you do?


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 paul@h... Tue Jun 20 18:24:54 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esm


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent