Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: support for substitution groups, support for redefines?

From: Jeff Rafter <lists@----------.--->
To: xmlschema-dev@--.---
Date: 7/9/2005 1:34:00 AM
Well, I know I have to be wrong being on the opposite side of an 
argument from the likes of Simon and Michael, but I still disagree. I 
think that the <redefine> facility maps very cleanly on to the old DTD 
practice of redefining items in the internal subset.

I also disagree that it is reaching into someone else's namespace-- 
especially considering the fact that <redefine> cannot operate as an 
<import>-- only as an <include>.

Apart from this I think that the facility is syntactically much more 
obvious. It allows the author to maintain a separation of concerns 
(original definition, extension points, imported items) while isolating 
the change to a single production in an extended schema.

It may not be right for all cases, but insomuch as it limits some of the 
other problems associated with type substitution (controlling usage of 
xsi:type for instance) it is assuredly preferable in some.

Respectfully,
Jeff Rafter

Simon Cox wrote:
> 
> I concur. "redefine" appears to be reaching into someone else's 
> namespace, and is thus conceptually as well as syntactically dubious.
> 
> OTOH subtitution groups are a good implementation of 
> inheritance/polymorphism.
> We use it that way in Geography Markup Language, where we map classes to 
> global elements.
> 
> Simon Cox
> 
> ----- Original Message ----- From: "Michael Kay" <mike@s...>
> To: "'Bryan Rasmussen'" <brs@i...>; <xmlschema-dev@w...>
> Sent: Saturday, July 09, 2005 7:18 AM
> Subject: RE: support for substitution groups, support for redefines?
> 
> 
>>
>> As far as I know Saxon supports redefines according to the spec, but:
>>
>> (a) there are very few test cases in the W3C test suite so it's hard 
>> to be
>> sure
>>
>> (b) by the nature of the facility, the design is very fragile
>>
>> (c) even if you follow the spec and the product implements it 
>> correctly, you
>> can get into an awful mess
>>
>> therefore I wouldn't recommend using it.
>>
>> Substitution groups are fine, I don't see any problem with them.
>>
>> Michael Kay
>> http://www.saxonica.com/
>>
>>> -----Original Message-----
>>> From: xmlschema-dev-request@w...
>>> [mailto:xmlschema-dev-request@w...] On Behalf Of Bryan Rasmussen
>>> Sent: 07 July 2005 08:33
>>> To: 'xmlschema-dev@w...'
>>> Subject: support for substitution groups, support for redefines?
>>>
>>>
>>>
>>> Hi
>>> Does anyone have a good overview of how well substitution groups and
>>> redefines are supported in various processors. The last big
>>> project where I
>>> used redefines extensively about half a year ago I had to redo halfway
>>> through after running into too many problems, problems where
>>> the redefine
>>> was proper and was supported by some processors but failed in
>>> others, even
>>> more insidious where cases where I had redefined incorrectly and it
>>> functioned in some processors or in some test instances only
>>> to fail later.
>>> This has put me off redefines, now I'm on something where
>>> redefines and
>>> substitution groups are being proposed as the extensibility
>>> mechanism. I've
>>> had misgivings about substitution groups, finding them somewhat overly
>>> complicated and have thus avoided them. How is their support?
>>>
>>> Cheers
>>> Bryan Rasmussen
>>>
>>>
>>
>>
>>
> 
> 
> 

From mike@s... Sun Jul 10 08:03:55 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50


transparent
Print
Mail
Digg
delicious
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