W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2007

RE: redefine and interoperability problems

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>
Message-ID: <7B3F99FF825A0D4BBC8A88F841420BDE578B2D2B28@NA-EXMSG-C117.redmond.corp.microsoft.com>

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.

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

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 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

             "Michael Kay"
             m>                                                         To
                                       "'W. Eliot Kimber'"
             04/05/2007 04:41          <ekimber@innodata-isogen.com>,
             AM                        <xmlschema-dev@w3.org>
                                       Eric Sirois/Toronto/IBM@IBMCA
                                       RE: redefine and interoperability

> > 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
without adding a version/variant qualifier to the name of the component.)

Michael Kay
Received on Saturday, 14 April 2007 00:01:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:12 UTC