- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Tue, 29 Sep 2009 09:57:53 -0600
- To: XMLSchema at XML4Pharma <XMLSchema@XML4Pharma.com>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, <xmlschema-dev@w3.org>
On 29 Sep 2009, at 05:24 , XMLSchema at XML4Pharma wrote: > We, the CDISC XML-Tech Governance Team (and other CDISC teams) have > developed a number of extensible standards for exchange of clinical > data and for submitting information to the regulatory authorities > (FDA). > > CDISC is a Standardization Organization active in the healthcare > world. > > Our extension mechanism is based on the “import” and “redefine” > elements of XML-Schema. > > We now have a serious dispute with one technology vendor (Altova) > about the way “import” and “redefine” are used. Instance files of > one of our extensions (so-called “define.xml”) validate well in all > major validators and XML-editors, except for the products of this > one vendor. > > When confronted with this result, the reaction of Altova essentially > is that “Altova is right, all others are wrong”. The dispute and > discussion with Altova can be followed at: > http://www.altova.com/forum/default.aspx?g=posts&m=1000005665 > > The issue were not so serious if it were not that our standard > “define.xml” is a standard for submission of information to the > regulatory authorities, and these are (mostly) using the Altova > product for validation. > > We now want to escalate the issue to the W3C itself, and would like > to know what the mechanism is to do so. > > Jozef Aerts > CDISC XML-Tech Governance Team > I believe that some standards bodies have mechanisms for requesting authoritative interpretations of doubtful points in specifications published by those bodies. W3C does not have any formal mechanism for such interpretations, but you can certainly request an opinion from the W3C XML Schema Working Group by sending mail to the XSD comments list at www-xml-schema-comments@w3.org (or by raising a Bugzilla issue against XSD 1.0). The public record shows, however, that the XML Schema Working Group has already addressed the question of what happens when the same schema document is referred to both by a direct import or include and indirectly through a reference to another schema document which redefines the first (see Bugzilla bugs 2330, 2557, 2824, and on related issues also 2826 and 5425, in the W3C public instance of Bugzilla at http://www.w3.org/Bugs/Public/). As the record shows, the Working Group has been unable to resolve those issues in part because the group has not been able to reach consensus on the meaning of the 1.0 specification in the cases in question. Reviewing the discussion record on the Altova forum I am struck by the repeated remark that the CDISC team has consulted "several distinguished members of the W3C XML-Schema working group" who confirmed CDISC's interpretation of the XSD 1.0 spec. I can only hope that these consultations took place some years ago, before the working group realized just how divergent its interpretations of the specification are; if you have consulted with any member of the working group in the last four years about this case, and they have failed to mention to you that the spec invites multiple contradictory interpretations, and that the working group has been unable to agree on what a single interpretation, then I fear they have misled you sadly. I'm also struck by the report that XML Spy is an outlier in its behavior on this case. The work I did in 2007 on an analogous case suggested that depending on how they were invoked, the eight processors tested behaved in nine or ten different ways (fourteen if you count error messages reporting different diagnoses of the problem as different behaviors). The work is described in a document available at http://www.cmsmcq.com/2007/schema_composition/model.xml (the test cases which elicit these different behaviors are described in section 5.2.2 and its subsctions). The XSD 1.0 specification does not explicitly address the case when the same schema document in referenced both directly (via import or include) and indirectly (via redefine). The rules for import specify that the components imported via the import or include should be present in the resulting schema; the discussion of redefine says that the effect of redefine is pervasive. Some readers interpret this to mean that the pervasive-redefinition rule overrides, or modifies the effect of, the import and include rules. On this reading the schema is legal and the components are present in their redefined form (and only that form). This reading effectively attaches to the rules for include and import an unspoken exception to the effect that the components imported or included are present in the resulting schema unless they are redefined by some other schema document reference. Other readers interpret the rules as requiring that the components in question should be present both in their original and in their redefined form, which means that the schema violates the rule that there must be at most one component of any kind with a given expanded name, and thus that the schema should be rejected. It is my personal belief that the most plausible interpretation of the specification is the latter; as you have observed, at least some implementors disagree and prefer the other interpretation. The inability of the XML Schema working group to agree on a normative interpretation of XSD 1.0 has led to the agreement to deprecate the redefine element in XSD 1.1. My personal recommendation is either to avoid redefine entirely or to avoid the use of schemaLocation information in your primary schema documents, restricting the identification of specific schema documents to top-level 'driver' documents, or to invocation-time parameters and options passed to the validator. I hope this helps. Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Tuesday, 29 September 2009 15:58:34 UTC