- From: Zafar Abbas <Zafar.Abbas@microsoft.com>
- Date: Fri, 13 Apr 2007 17:01:11 -0700
- To: Eric Sirois <esirois@ca.ibm.com>, Michael Kay <mike@saxonica.com>
- CC: "'W. Eliot Kimber'" <ekimber@innodata-isogen.com>, "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
Eric, The circular group reference error you are seeing in .NET would be with .NET 1.1. This issue has been fixed in .NET 2.0 where you should not see that error. Let me know if you have any questions. Thanks, Zafar Abbas -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Eric Sirois Sent: Friday, April 13, 2007 6:59 AM To: Michael Kay Cc: 'W. Eliot Kimber'; xmlschema-dev@w3.org Subject: RE: redefine and interoperability problems Unfortunately, for the DITA XML Schemas we had to make use of <xs:redefine> in order to replicate substitutionGroups to avoid making use of XML Schema inheritance mechanism. At the moment, there are two issues with make it hard for folks to use of the mechanism across most/all XML parsers. It's mainly the inconsistency between implementations. MSXML .NET - returns an error when including a self-reference to the group when extending. Xerces-C - must redefine the schema document where the component to be redefined is defined. There is a bug against Xerces-J open at the moment https://issues.apache.org/jira/browse/XERCESJ-1219. This defect will make Xerces-C and Xerces-J behave in the same manner - redefine before it's included. Jirka's example using Xerces-C would thrown an error stating something to the effect that the component is defined in the schema document that is referenced. I've asked our XML Schema representative to add some clarification to spec regarding the order in which need to occur when redefining components. (redefine/include vs. include/redefine). It may be that once the spec has a bit more clarity this defect will away or there will a lot of users who will have schemas that are no longer valid. Kind regards, Eric Eric A. Sirois Staff Software Developer DB2 Universal Database - Information Development DITA Migration and Tools Development IBM Canada Ltd. - Toronto Software Lab Email: esirois@ca.ibm.com Blue Pages (Internal) "Transparency and accessibility requirements dictate that public information and government transactions avoid depending on technologies that imply or impose a specific product or platform on businesses or citizens" - EU on XML-based office document formats. "Michael Kay" <mike@saxonica.co m> To "'W. Eliot Kimber'" 04/05/2007 04:41 <ekimber@innodata-isogen.com>, AM <xmlschema-dev@w3.org> cc Eric Sirois/Toronto/IBM@IBMCA Subject RE: redefine and interoperability problems > > I personally think xs:redefine is one of those facilities > (xsi:nil is > > another) where you're better off pretending it doesn't exist. > > Implementors don't have that luxury, but users do. > > Hmm. The DITA schemas depend entirely on xs:redefine in order > to provide the equivalent configurability to the parameter > entities in the DTD versions, that is, using schemas can > redefine the members of groups that are then referenced from > the used schemas. I have successfully tackled that problem by writing code that transforms schemas (or near-schemas) to provide the configurability. I think it's better to have this kind of capability in a separate language (indeed, a separate architectural component of the system) rather than building in self-modification semantics to the language itself. I would have thought that the configurability you describe above could be achieved by the even simpler technique of URI-switching - that is, redirecting the URI in an xs:include to refer to a selected variant of the included module. xs:redefine is particularly horrible once schemas start to have wider scope than a single validation episode, specifically, when multiple variants of a schema component have to coexist. In particular, if you've got an XML database whose contents are described by a family of schemas, the notion that xs:redefine is "pervasive" could be taken to mean that it effectively alters schemas that are used in a quite unrelated part of the database, including schemas describing documents that were stored years ago. That's clearly untenable; but finding a different definition of "pervasive" that actually works in this environment isn't easy. Saxon's approach is to say that once a schema component has been "used" (in some carefully defined sense) further redefinition is banned. (Having said that, this problem affects any technique that leaves you with multiple versions or variants of a schema component coexisting. I think Roger Needham once said that all problems in computer science can be solved by adding another level of indirection; and certainly the problem of handling multiple coexisting versions of schema components appears insoluble without adding a version/variant qualifier to the name of the component.) Michael Kay http://www.saxonica.com/
Received on Saturday, 14 April 2007 00:01:21 UTC