http://www.altova.com/ Altova accelerates application development and data management projects with software and solutions that enhance productivity and maximize results. As an innovative, customer-focused company and the creator of XMLSpy and other leading XML, data administration, UML, and Web services tools, Altova is the choice of over 3 million clients worldwide, including virtually every Fortune 500 company. With customers ranging from vast development teams in the world’s largest organizations to progressive one-person shops, Altova’s line of software applications fulfills a broad spectrum of business needs. Altova is an active member of the World Wide Web Consortium (W3C) and Object Management Group (OMG) and is committed to delivering standards-based platform-independent solutions that are powerful, affordable, and easy to use. Altova was founded in 1992 and has headquarters in Beverly, Massachusetts and Vienna, Austria. en-us Copyright © 2005, 2006, 2007 Altova GmbH. All rights reserved. Altova, XMLSpy, MapForce, StyleVision, SemanticWorks, SchemaAgent, UModel, DiffDog, and Authentic are trademarks and/or registered trademarks of Altova GmbH in the United States and/or other countries. The names of and reference to other companies and products mentioned herein may be the trademarks of their respective owners. Tue, 03 Jun 2008 10:00:00 EDT Tue, 03 Jun 2008 10:00:00 EDT Authentic RSS Editor, visit www.altova.com for details pr@altova.com webmaster@altova.com http://www.altova.com/images/logos/altova_right_120.gif http://www.altova.com/ 120 24 Altova Logo Thank you all for your valuable feedback. I think Henry put it most succintly: "The spec doesn't provide a mechanism by which a schema can constrain the document element of schema-valid documents." That's what I was wanting to know. I apologise if I used confusing terminology in trying to explain my problem! Regards, Richard. -- View this message in context: http://old.nabble.com/Possible-to-restrict-top-level-xs%3Aelement-names--tp26227610p26249237.html Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.]]> http://www.altova.com/list/xmlschema-dev/200911/msg1000306254.html > (b) make sure your processor distinguishes between elements > with [validity]=invalid and those with [validity]=notKnown > (again, how you do this is between you and your processor, > and out of scope for the XSD spec); and You might like to note that Saxon's schema processor, and perhaps some other products, expose this distinction by allowing you to select "strict" or "lax" validation. Strict validation fails if the outcome is [validity]=notKnown, whereas lax validation succeeds. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200911/msg1000306212.html On 5 Nov 2009, at 23:58 , kennardconsulting wrote: > > I'm generating a bunch of XML Schemas that look roughly like: > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > </xs:schema> > > You can see the actual ones http://metawidget.org/xsd here . My > question > is, this schema allows me to declare 'foo' and 'bar' in my XML > document, but > doesn't restrict me declaring, say, 'baz'. I'm not quite sure what you're saying. Where I come from, it is natural to speak of declaring 'foo' and 'bar' elements in a schema document (as is done in the skeleton you give), but odd to speak of 'declaring' elements in the XML instance being validated. If you mean "how do I prevent someone else writing a schema document for my target namespace and including a top-level baz element in it?", the answer is that you can't prevent other people from writing what they like in documents on their own hard disks. The world is just structured that way. On the other hand, you don't have to use the schema documents on their hard disks when you validate. If you want to ensure that in a particular validation episode 'foo' and 'bar' will be global elements in the target namespace, and 'baz' won't be, you just need to arrange with your schema validator, at invocation time, that it should read your schema documents, and not the ones on other people's disks that include declaration for 'baz'. How you arrange with a validator to read certain schema documents and not read others is out of scope of the schema language itself; if a particular validator does not allow you to control things with the degree of precision you need, it's a quality issue and you should look for a new validator. If on the other hand you mean "how do I keep someone from using a 'baz' element in my namespace?", again, the universe is so structured that nothing you or XSD or any other schema language can do could possibly prevent that. The most you can do is try to arrange that such a usage counts as invalid when the document is validated against your schema. So consider the question "how do I ensure that when a user uses a 'baz' element in my namespace, it's marked invalid?" The answer is, roughly: (a) tell the validator to read your schema document and not some bogus one which defines 'baz' (see above); (b) make sure your processor distinguishes between elements with [validity]=invalid and those with [validity]=notKnown (again, how you do this is between you and your processor, and out of scope for the XSD spec); and (c) make sure your own code that invokes the validator rejects the cases where [validity]=notKnown. > I was expecting something like... > > <xs:schema final="#all"> > > ....so that I could 'close' the set of possible xs:element names. Or > maybe > that the set was closed by default and I'd need... > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > <xs:any /> > </xs:schema> > > ....to make it open. But instead the set of top-level xs:element names > appears 'open' by default and I can't find a way to close it? I have > looked > all over the specs and in this forum, sorry if I'm being dumb. I'm not sure what you mean by open and closed sets of elements (or element names) here. I'm also not sure whether by "top-level" you mean "can be used as the root element of a document" or "defined on the top level of a schema document; not local to a complex type". But in a way, I guess, it doesn't really matter: XSD's design says, essentially, that the way you specify "these declarations, and no others" is to say just that, but at validation time, not at schema specification time. I hope this helps. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************]]> http://www.altova.com/list/xmlschema-dev/200911/msg1000306182.html I'm not quite sure what you are asking. Are you trying to restrict how your schema can be extended, or are you trying to restrict what is allowed in an instance document? Perhaps you have a conceptual misunderstanding? Note that <xs:schema ...> <xs:element name="foo"/> <xs:element name="bar"/> </xs:schema> is not the same as <xs:schema ...> <xs:choice> <xs:element name="foo"/> <xs:element name="bar"/> </xs:choice> </xs:schema> (which isn't legal btw). That is, the children of your <schema> element do not represent a model for your instance documents, which is perhaps how you are thinking of it? Rather, they declare the elements, attributes, and types according to which an instance document may be validated. (Note by the way, that there are different approaches to validating documents against schemas, see http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#validation_outcome). I don't believe you can prevent someone from including your schema document into theirs while at the same time adding more global elements, if that's what you are trying to avoid. Kevin -- Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) http://www.obj-sys.com On 11/6/2009 1:58 AM, kennardconsulting wrote: > Hi guys, > > I'm generating a bunch of XML Schemas that look roughly like: > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > </xs:schema> > > You can see the actual ones http://metawidget.org/xsd here . My question > is, this schema allows me to declare 'foo' and 'bar' in my XML document, but > doesn't restrict me declaring, say, 'baz'. I was expecting something like... > > <xs:schema final="#all"> > > ....so that I could 'close' the set of possible xs:element names. Or maybe > that the set was closed by default and I'd need... > > <xs:schema ...> > <xs:element name="foo"/> > <xs:element name="bar"/> > <xs:any /> > </xs:schema> > > ....to make it open. But instead the set of top-level xs:element names > appears 'open' by default and I can't find a way to close it? I have looked > all over the specs and in this forum, sorry if I'm being dumb. > > Regards, > > Richard. >]]> http://www.altova.com/list/xmlschema-dev/200911/msg1000306170.html Hi guys, I'm generating a bunch of XML Schemas that look roughly like: <xs:schema ...> <xs:element name="foo"/> <xs:element name="bar"/> </xs:schema> You can see the actual ones http://metawidget.org/xsd here . My question is, this schema allows me to declare 'foo' and 'bar' in my XML document, but doesn't restrict me declaring, say, 'baz'. I was expecting something like... <xs:schema final="#all"> ....so that I could 'close' the set of possible xs:element names. Or maybe that the set was closed by default and I'd need... <xs:schema ...> <xs:element name="foo"/> <xs:element name="bar"/> <xs:any /> </xs:schema> ....to make it open. But instead the set of top-level xs:element names appears 'open' by default and I can't find a way to close it? I have looked all over the specs and in this forum, sorry if I'm being dumb. Regards, Richard. -- View this message in context: http://old.nabble.com/Possible-to-restrict-top-level-xs%3Aelement-names--tp26227610p26227610.html Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.]]> http://www.altova.com/list/xmlschema-dev/200911/msg1000306167.html Altova is pleased to announce general availability version 2010 of its MissionKit XML, database, and UML tools. v2010 is our MOST WANTED release and includes over 70 new customer-requested features. Just a few of these include: * Support for WSDL 2.0, JSON, and SysML technologies * New stylesheet design paradigm with advanced support for electronic form design * Enhanced XBRL functionality * Database schema comparison * And much more More info and screenshots are available at <http://www.altova.com/whatsnew.html> Download a fully functional free trial at <http://www.altova.com/download.html> Best regards, Liz Liz Andrews Technical Marketing Manager Altova, Inc. www.altova.com ________________________________ This e-mail and any attachments are intended only for the person/entity to which they are addressed and may contain confidential and/or privileged material. If you received this in error, please notify the sender and delete the message. Liz Andrews Technical Marketing Manager Altova, Inc. www.altova.com ________________________________ This e-mail and any attachments are intended only for the person/entity to which they are addressed and may contain confidential and/or privileged material. If you received this in error, please notify the sender and delete the message.]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305581.html Henry Thompson writes: > That was part of the compromise. Stated differently: you can infer that there were a significant number of people involved who strongly took the opposite position from yours, and the default you see was in deference to their views of what the community needed. As already noted, it was a long and difficult discussion, with strongly held opinions on both sides. I don't think anyone thought the resulting design was particularly appealing, but given the strongly divergent opinions about what users needed and/or about how namespaces were supposed to be used, the design had the advantage of letting users choose. FWIW: I tend to sympathize with George's feeling that most users do want the qualified idiom, that qualified would have been a better default, etc. Still, it's way too late to reopen it now, and there are schemas out in the wild that use both options as far as I know. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- ht@inf.ed.ac.uk (Henry S. Thompson) Sent by: xmlschema-dev-request@w3.org 10/26/2009 10:52 AM To: lists@fgeorges.org cc: Michael Kay <mike@saxonica.com>, xmlschema-dev@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: Re: redefine and target namespace -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Georges writes: > Henry S. Thompson wrote: > >> Without going into tedious and confidential details about >> personalities and working group discussions, suffice it to say >> that the design we have was the only one that included both >> possibilities which the WG could reach consensus on. > > Yes, but that does not answer the interesting question: why the > chosen default value ;-) That was part of the compromise. ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFK5beVkjnJixAXWBoRAoT5AJ4yFDcwJ5ffeptvNEzg6ORziuap5gCdFrbr df9/0oDB1kNHtEXZPaHqEks= =ciuI -----END PGP SIGNATURE-----]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305358.html Henry S. Thompson wrote: Hi, > Without going into tedious and confidential details about > personalities and working group discussions, suffice it to say > that the design we have was the only one that included both > possibilities which the WG could reach consensus on. Yes, but that does not answer the interesting question: why the chosen default value ;-) Regards, -- Florent Georges http://www.fgeorges.org/]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305353.html Michael Kay wrote: Hi, > > I thought the element 'b' was defined in the target > > namespace, but it seems it has to be in no namespace. > Just as if you didn't use redefine, your local element > declaration will only be in the target namespace if you specify > elementFormDefault="qualified" <blush>Ouch!</blush> It's been a long time since I've been fooled by this one. I guess I was focused on the redefine... Sorry for the noise and thanks for the quick answer! Regards, -- Florent Georges http://www.fgeorges.org/]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305314.html > I thought the element 'b' was defined in the target namespace, but it seems it has to be in no namespace. Just as if you didn't use redefine, your local element declaration will only be in the target namespace if you specify elementFormDefault="qualified" on your xs:schema element. (Or, of course, form="qualified" on the local element declaration itself, but no-one ever does that.) > Is it really the intent of the spec? Yes. I've never heard an adequate explanation of why this extraordinary decision was made, but in practice everyone changes the default by using elementFormDefault="qualified". Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305305.html Hi, I have a schema document that redefines a complex type as following: <xs:redefine schemaLocation="redefine.xsd"> <xs:complexType name="root"> <xs:complexContent> <xs:extension base="tns:root"> <xs:sequence> <xs:element name="b" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> I thought the element 'b' was defined in the target namespace, but it seems it has to be in no namespace. Is it really the intent of the spec? Did I do anything wrong? I use Xerces 2 for Java (as in Java SE 6.) redefine.xsd: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="tns" targetNamespace="tns" elementFormDefault="qualified"> <xs:element name="root" type="tns:root"/> <xs:complexType name="root"> <xs:sequence> <xs:element name="a" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:schema> redefine-red.xsd: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="tns" xmlns:tns="tns"> <xs:redefine schemaLocation="redefine.xsd"> <xs:complexType name="root"> <xs:complexContent> <xs:extension base="tns:root"> <xs:sequence> <xs:element name="b" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> <xs:element name="redefined" type="tns:root"/> </xs:schema> Valid redefine.xml: <tns:redefined xmlns:tns="tns"> <tns:a>bla</tns:a> <b>bla</b> </tns:redefined> Expected valid redefine.xml (but actually invalid): <redefined xmlns="tns"> <a>bla</a> <b>bla</b> </redefined> Regards, -- Florent Georges http://www.fgeorges.org/]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305304.html Very well. Thank you, Michael and Michael. On 10/22/2009 4:08 AM, Michael Kay wrote: >> How will the prefix in the ref attribute in the >> attributeGroup element be handled? If D2' is the result of >> applying the xs:override transform, and D2' contains an >> element information item that is identical to the one for the >> <attributeGroup>, I expect it will have [in-scope namespaces] >> based on what we see above; namely, the qrs prefix will >> necessarily resolve to "uri:example.com". Is that correct? >> > > Yes. In fact, this doesn't even depend on the stylesheet being schema-aware > and on @ref being known to be a QName. The element is copied using > <xsl:copy-of>, which copies all the in-scope namespaces of an element, > including therefore the namespace binding for "qrs". > >> Also, a second question. I don't speak XSLT, but the >> stylesheet given for the transformation for xs:override >> includes a comment that says : >> >> <!--* change xs:override elements: children which match >> * children of $overrideElement are replaced, others are >> * kept, and at the end all children of $overrideElement >> * not already inserted are added. >> *--> >> >> The "at the end all children..." clause doesn't appear to be >> consistent with the description that precedes the stylesheet. >> Specifically, I don't see where a child of O1 that does not >> correspond to a child of D2 >> would be put into D2'. Perhaps I misunderstand the comment, >> or perhaps >> it isn't consistent with the XSLT that is there (again, I >> don't speak XSLT). Is there an inconsistency here? >> > > I think Michael Sperberg McQueen has explained this part. It is complex and > my brain aches a little every time I look at it, but I think I have > convinced myself that it works. It would benefit, however, from some serious > testing: there is an assumption that we will produce tests before exiting > CR. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305118.html > > How will the prefix in the ref attribute in the > attributeGroup element be handled? If D2' is the result of > applying the xs:override transform, and D2' contains an > element information item that is identical to the one for the > <attributeGroup>, I expect it will have [in-scope namespaces] > based on what we see above; namely, the qrs prefix will > necessarily resolve to "uri:example.com". Is that correct? Yes. In fact, this doesn't even depend on the stylesheet being schema-aware and on @ref being known to be a QName. The element is copied using <xsl:copy-of>, which copies all the in-scope namespaces of an element, including therefore the namespace binding for "qrs". > > Also, a second question. I don't speak XSLT, but the > stylesheet given for the transformation for xs:override > includes a comment that says : > > <!--* change xs:override elements: children which match > * children of $overrideElement are replaced, others are > * kept, and at the end all children of $overrideElement > * not already inserted are added. > *--> > > The "at the end all children..." clause doesn't appear to be > consistent with the description that precedes the stylesheet. > Specifically, I don't see where a child of O1 that does not > correspond to a child of D2 > would be put into D2'. Perhaps I misunderstand the comment, > or perhaps > it isn't consistent with the XSLT that is there (again, I > don't speak XSLT). Is there an inconsistency here? I think Michael Sperberg McQueen has explained this part. It is complex and my brain aches a little every time I look at it, but I think I have convinced myself that it works. It would benefit, however, from some serious testing: there is an assumption that we will produce tests before exiting CR. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305101.html On 21 Oct 2009, at 15:22 , Kevin Braun wrote: > Here's an XSD 1.1 <override> question. > Suppose I have: > <schema ... xmlns:qrs="uri:example.com"> > <override ...> > <complexType name="SomeType"> > <attributeGroup ref="qrs:abc"/> > </complexType> > </override> > ... > </schema> > How will the prefix in the ref attribute in the attributeGroup > element be handled? > If D2' is the result of applying the xs:override transform, and D2' > contains an element information item that is identical to the one > for the <attributeGroup>, I expect it will have [in-scope > namespaces] based on what we see above; namely, the qrs prefix will > necessarily resolve to "uri:example.com". Is that correct? That's certainly the intent. The namespace fixup rules of XSLT are complicated enough that I don't want to say more about how it works in detailuntil I have a chance to work the example through in more detail. But at a high level, the stylesheet knows the type of attributeGroup/@ref, so it knows there are QNames around which may depend on the current namespace bindings. And when the node is re-serialized in its new context, it should not have lost any namespace bindings. (The prefix may change, of course, but not the expanded name denoted by qrs:abc.) > Also, a second question. I don't speak XSLT, but the stylesheet > given for the transformation for xs:override includes a comment > that says : > <!--* change xs:override elements: children which match > * children of $overrideElement are replaced, others are > * kept, and at the end all children of $overrideElement > * not already inserted are added. > *--> > The "at the end all children..." clause doesn't appear to be > consistent with the description that precedes the stylesheet. > Specifically, I don't see where a child of O1 that does not > correspond to a child of D2 would be put into D2'. Perhaps I > misunderstand the comment, or perhaps it isn't consistent with the > XSLT that is there (again, I don't speak XSLT). Is there an > inconsistency here? The comment correctly describes the template which follows it, I think. And it also matches the behavior described in rule 4 of the prose description. The template applies to xs:override elements within D2, so we are dealing with two override elements: O1, which is the override we are trying to handle by performing the transformation, and E2 (the override child of D2), which is in the process of being transformed into a new override element O2, which will appear within D2'. O2 contains (1) children corresponding to the children of E2. If a particular child of E2 matches some child of O1, then what O2 contains is the child of O1 (the child of E2 has been overridden by the child of O1). If a particular child of E2 matches no child of O1, then O2 has that child unchanged. O2 also contains (2) children corresponding to the children of O1. If a child of O1 matches a child of E2, it's present in O2 as already described above. If a child of O1 matches no child of E2, it's copied into O2 without change. Example: Schema document D1 overrides schema document D2, and its override element contains declarations for elements A, B, and C. <schema xmlns="http://www.w3.org/2001/XMLSchema"> <override id="d1o" schemaLocation="D2.xsd"> <element name="A" type="anyURI"/> <element name="B" type="boolean"/> <element name="C" type="decimal"/> </override> </schema> Schema document D2 overrides schema document D3, and the override element contains declarations for elements C and D. <schema xmlns="http://www.w3.org/2001/XMLSchema"> <override id="d2o" schemaLocation="D3.xsd"> <element name="C" type="double"/> <element name="D" type="duration"/> </override> </schema> Schema document D3 declares elements A, B, C, D, and E. <schema xmlns="http://www.w3.org/2001/XMLSchema"> <element name="A" /> <element name="B" /> <element name="C" /> <element name="D" /> <element name="E" /> </schema> Observe first that the end result needs to have A, B, C, and D declared as anyURI, boolean, decimal, and duration, respectively. The first draft of override said, essentially, "That's too complicated, it's not going to happen", and override only affected elements declared in D2. The result here would have been that of all the overrides in D1, only the override of C would have had any effect. (At least, that's my recollection; I have not gone back to review the details of the original proposal.) The WG was troubled by the inconvenience this represented, and wanted the overrides in D1 to affect not only declarations in D2 but declarations in documents referenced by D2. We spent some time working out how to make this happen; the mechanism in the stylesheet is the result. The effect of the override of D2 in D1 is, according to the spec, the same as an include of the transformed schema document D2', which would look something like this: <schema xmlns="http://www.w3.org/2001/XMLSchema"> <override id="d2o" schemaLocation="D3.xsd"> <element name="C" type="decimal"/> <element name="D" type="duration"/> <element name="A" type="anyURI"/> <element name="B" type="boolean"/> </override> </schema> Note that the overrides for A and B are included here, even though they matched nothing in override d2o. They are needed to ensure that A and B are overridden WHEREVER they were declared. The meaning of the override in D2' is, again, the same as the meaning of an include on a transformed target D3', reading: <schema xmlns="http://www.w3.org/2001/XMLSchema"> <element name="A" type="anyURI"/> <element name="B" type="boolean"/> <element name="C" type="decimal"/> <element name="D" type="duration"/> <element name="E" /> </schema> If we rewrite the overriding schema documents as well, to show the change from override to include, we end up with an imaginare D1' reading <schema xmlns="http://www.w3.org/2001/XMLSchema"> <include id="d1o" schemaLocation="D2''.xsd"/> </schema> And a D2'' reading <schema xmlns="http://www.w3.org/2001/XMLSchema"> <include id="d2o" schemaLocation="D3'.xsd"/> </schema> If the unmatched overrides of d1o had NOT been copied into the modified version of d2o, then the final result would have had a D3' of the form <schema xmlns="http://www.w3.org/2001/XMLSchema"> <element name="A"/> <element name="B"/> <element name="C" type="decimal"/> <element name="D" type="duration"/> <element name="E" /> </schema> By copying even the unmatched children of O1 into O2, we ensure that the declarations of O1 will override other declarations of the same component name, no matter where those other declarations occur in the target set of O1. The transformation of include elements into overide elements serves the same purpose. I hope this helps. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305080.html Hi, Here's an XSD 1.1 <override> question. Suppose I have: <schema ... xmlns:qrs="uri:example.com"> <override ...> <complexType name="SomeType"> <attributeGroup ref="qrs:abc"/> </complexType> </override> ... </schema> How will the prefix in the ref attribute in the attributeGroup element be handled? If D2' is the result of applying the xs:override transform, and D2' contains an element information item that is identical to the one for the <attributeGroup>, I expect it will have [in-scope namespaces] based on what we see above; namely, the qrs prefix will necessarily resolve to "uri:example.com". Is that correct? Also, a second question. I don't speak XSLT, but the stylesheet given for the transformation for xs:override includes a comment that says : <!--* change xs:override elements: children which match * children of $overrideElement are replaced, others are * kept, and at the end all children of $overrideElement * not already inserted are added. *--> The "at the end all children..." clause doesn't appear to be consistent with the description that precedes the stylesheet. Specifically, I don't see where a child of O1 that does not correspond to a child of D2 would be put into D2'. Perhaps I misunderstand the comment, or perhaps it isn't consistent with the XSLT that is there (again, I don't speak XSLT). Is there an inconsistency here? Regards, Keviin -- Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) http://www.obj-sys.com]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305073.html Hi Scott, Trang can generate XML Schema from a set of XML files http://code.google.com/p/jing-trang/ Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com Tsao, Scott wrote: > I am wondering if there are good tools that would enable (auto) > generation of XML schema from multiple instances of sample XML document. > > It seems to me that one should be able to specify certain parameters for > the resulting schema, e.g., the design pattern [1] to be followed. > > Any comments or suggestions? > > [1] > http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html > > > Thanks, > > /Scott Tsao/ $BAbThT"(B > Associate Technical Fellow > The Boeing Company >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305011.html Hello. I downloaded the XSV validator and am a novice user I think because from the hours I have spent looking for set up instructions, I cannot find them. Can you provide the steps I need to follow to set up my validator? Janell Craig Business Analyst Oakland Schools<http://oakland.k12.mi.us> Technology Services<http://www.oakland.k12.mi.us/Departments/TechnologyServices/tabid/932/Default.aspx> 2111 Pontiac Lake Rd. Waterford, MI 48328 (Ofc) 248-209-2020 (Fax) 248-209-2207]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000305009.html I've had good results on this using Stylus Studio. It works from a single instance document, but you can always combine multiple instances into one before you start. There is some control over the design patterns it uses, but I generally find the default settings are quite usable. Of course you have to tidy up the generated schema by hand afterwards, for example to make intelligent decisions about when to use enumerations and patterns in your simple types, or when to impose a hierarchy of types or substitution groups, but I find it's often a good way of creating a first cut. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _____ From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Tsao, Scott Sent: 20 October 2009 02:06 To: xmlschema-dev@w3.org Subject: Tools to Generate XSD from Sample Instances I am wondering if there are good tools that would enable (auto) generation of XML schema from multiple instances of sample XML document. It seems to me that one should be able to specify certain parameters for the resulting schema, e.g., the design pattern [1] to be followed. Any comments or suggestions? [1] http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/ techart/design_patterns.html Thanks, Scott Tsao $BAbThT"(B Associate Technical Fellow The Boeing Company]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304992.html My good advice: don't. or at least, do not expect too much of it. If you do, you will still need to do a lot of manual work afterwoods improving your schema. For example, if some attributes are enumerated, how do you know that ? And if you do, how are you sure you have all possible values in your schema ? How do you know whether the minOccurs for a child element should be 0 or 1 ? Essentially, automated generation can only be a very first step. I have seen cases where a believe that XML-Schemas can be generated automatically, without any afterwork, has led to disaster. For example, the HL7-v3 messages are auto-generated from UML diagrams. At least as far as I know, they are not improved after that by someone who has knowledge of XML-Schema. The result is that the whole stuff is overcomplicated, illogical and even bad XML. I can advice anyone that wishes to generate XML-Schemas to first learn XML-Schema. Personally, I prefer to make a good model first (not using UML) and then write the XML-Schema by hand. Best, Jozef Aerts XML4Pharma ----- Original Message ----- From: Tsao, Scott To: xmlschema-dev@w3.org Sent: Tuesday, October 20, 2009 3:06 AM Subject: Tools to Generate XSD from Sample Instances I am wondering if there are good tools that would enable (auto) generation of XML schema from multiple instances of sample XML document. It seems to me that one should be able to specify certain parameters for the resulting schema, e.g., the design pattern [1] to be followed. Any comments or suggestions? [1] http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html Thanks, Scott Tsao $BAbThT"(B Associate Technical Fellow The Boeing Company]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304991.html I am wondering if there are good tools that would enable (auto) generation of XML schema from multiple instances of sample XML document. It seems to me that one should be able to specify certain parameters for the resulting schema, e.g., the design pattern [1] to be followed. Any comments or suggestions? [1] http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html Thanks, Scott Tsao $BAbThT"(B Associate Technical Fellow The Boeing Company]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304989.html This looks correct (from visual inspection). To run it you will need Saxon 9.2 or the development version of Xerces (I can't speak for Xerces). Most schema tools do not yet support XSD 1.1, and both these two are incomplete implementations. You don't need to change the xs:schema element in order to use XSD 1.1. All you need to do is to use an XSD 1.1 processor. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _____ From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Bence Takács Sent: 19 October 2009 16:22 To: xmlschema-dev@w3.org Subject: Re: XML schema Hi, Michael Would it be something like this? <xs:attribute name="attribute_id" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:assert test="@attribute_id=Attributes/Attribute/@id or @attribute_id='id'"> </xs:restriction> </xs:simpleType> </xs:attribute> We are using saxon8 to parse and eclipse and altova xml spy to edit xml. Are they support 1.1? Is 1.1 backward compatible with 1.0? I mean: is it enough to change the header of the xml and xsd or the whole xsd and xml should have been changed? Is this the correct header for xsd? <?xml version="1.1" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault=" unqualified"> Because both eclipse and xml spy says that it is not valid. Thanks for help. Regards: Bence On Mon, Oct 19, 2009 at 12:27 AM, Michael Kay <mike@saxonica.com> wrote: I don't think this can be done in XSD 1.0 It can be done in XSD 1.1, of course, using assertions. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs > Sent: 18 October 2009 11:32 > To: xmlschema-dev@w3.org > Subject: XML schema > > Hi > > I have an xml schema which restricts the > Indexes/Tag/@attribute_id values to the ones are defined in > the parent element's Attributes/Attribute/@id. Is there a way > to extend this and enable one (or more) different static > values for example "id"? > There are more Indexes/Tag and Attributes/Attribute tags and > i would like to use this restriction only for thoose that has > the same parent. > > Here is my current configuration: > > .... > <xs:element name="Attributes"> > <xs:complexType> > <xs:sequence> > <xs:element name="Attribute" maxOccurs="unbounded"> > <xs:complexType> > <xs:complexContent> > <xs:extension base="Attribute_Type"> > <xs:attribute name="typedef_id" type="xs:string" > use="required"/> > </xs:extension> > </xs:complexContent> > </xs:complexType> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > .... > <xs:element name="Indexes" minOccurs="0"> > <xs:complexType> > <xs:sequence> > <xs:element name="Tag" maxOccurs="unbounded"> > <xs:complexType> > <xs:attribute name="attribute_id" use="required"> > <xs:simpleType> > <xs:restriction base="xs:string"> > <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/> > </xs:restriction> > </xs:simpleType> > </xs:attribute> > </xs:complexType> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > .... > .... > <xs:key name="ATTRIBUTE"> > <xs:selector xpath="Attributes/Attribute"/> > <xs:field xpath="@id"/> > </xs:key> > <xs:keyref name="X001" refer="ATTRIBUTE"> > <xs:selector xpath="Indexes/Tag"/> > <xs:field xpath="@attribute_id"/> > </xs:keyref> > .... > > > Thanks: > Bence > -- > View this message in context: > http://www.nabble.com/XML-schema-tp25945562p25945562.html > Sent from the w3.org - xmlschema-dev mailing list archive at > Nabble.com. > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304986.html Hi, Michael Would it be something like this? <xs:attribute name="attribute_id" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:assert test="@attribute_id=Attributes/Attribute/@id or @attribute_id='id'"> </xs:restriction> </xs:simpleType> </xs:attribute> We are using saxon8 to parse and eclipse and altova xml spy to edit xml. Are they support 1.1? Is 1.1 backward compatible with 1.0? I mean: is it enough to change the header of the xml and xsd or the whole xsd and xml should have been changed? Is this the correct header for xsd? <?xml version="1.1" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> Because both eclipse and xml spy says that it is not valid. Thanks for help. Regards: Bence On Mon, Oct 19, 2009 at 12:27 AM, Michael Kay <mike@saxonica.com> wrote: > I don't think this can be done in XSD 1.0 > > It can be done in XSD 1.1, of course, using assertions. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > > -----Original Message----- > > From: xmlschema-dev-request@w3.org > > [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs > > Sent: 18 October 2009 11:32 > > To: xmlschema-dev@w3.org > > Subject: XML schema > > > > Hi > > > > I have an xml schema which restricts the > > Indexes/Tag/@attribute_id values to the ones are defined in > > the parent element's Attributes/Attribute/@id. Is there a way > > to extend this and enable one (or more) different static > > values for example "id"? > > There are more Indexes/Tag and Attributes/Attribute tags and > > i would like to use this restriction only for thoose that has > > the same parent. > > > > Here is my current configuration: > > > > .... > > <xs:element name="Attributes"> > > <xs:complexType> > > <xs:sequence> > > <xs:element name="Attribute" maxOccurs="unbounded"> > > <xs:complexType> > > <xs:complexContent> > > <xs:extension base="Attribute_Type"> > > <xs:attribute name="typedef_id" type="xs:string" > > use="required"/> > > </xs:extension> > > </xs:complexContent> > > </xs:complexType> > > </xs:element> > > </xs:sequence> > > </xs:complexType> > > </xs:element> > > .... > > <xs:element name="Indexes" minOccurs="0"> > > <xs:complexType> > > <xs:sequence> > > <xs:element name="Tag" maxOccurs="unbounded"> > > <xs:complexType> > > <xs:attribute name="attribute_id" use="required"> > > <xs:simpleType> > > <xs:restriction base="xs:string"> > > <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/> > > </xs:restriction> > > </xs:simpleType> > > </xs:attribute> > > </xs:complexType> > > </xs:element> > > </xs:sequence> > > </xs:complexType> > > </xs:element> > > .... > > .... > > <xs:key name="ATTRIBUTE"> > > <xs:selector xpath="Attributes/Attribute"/> > > <xs:field xpath="@id"/> > > </xs:key> > > <xs:keyref name="X001" refer="ATTRIBUTE"> > > <xs:selector xpath="Indexes/Tag"/> > > <xs:field xpath="@attribute_id"/> > > </xs:keyref> > > .... > > > > > > Thanks: > > Bence > > -- > > View this message in context: > > http://www.nabble.com/XML-schema-tp25945562p25945562.html > > Sent from the w3.org - xmlschema-dev mailing list archive at > > Nabble.com. > > > > > > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304984.html I don't think this can be done in XSD 1.0 It can be done in XSD 1.1, of course, using assertions. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs > Sent: 18 October 2009 11:32 > To: xmlschema-dev@w3.org > Subject: XML schema > > Hi > > I have an xml schema which restricts the > Indexes/Tag/@attribute_id values to the ones are defined in > the parent element's Attributes/Attribute/@id. Is there a way > to extend this and enable one (or more) different static > values for example "id"? > There are more Indexes/Tag and Attributes/Attribute tags and > i would like to use this restriction only for thoose that has > the same parent. > > Here is my current configuration: > > .... > <xs:element name="Attributes"> > <xs:complexType> > <xs:sequence> > <xs:element name="Attribute" maxOccurs="unbounded"> > <xs:complexType> > <xs:complexContent> > <xs:extension base="Attribute_Type"> > <xs:attribute name="typedef_id" type="xs:string" > use="required"/> > </xs:extension> > </xs:complexContent> > </xs:complexType> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > .... > <xs:element name="Indexes" minOccurs="0"> > <xs:complexType> > <xs:sequence> > <xs:element name="Tag" maxOccurs="unbounded"> > <xs:complexType> > <xs:attribute name="attribute_id" use="required"> > <xs:simpleType> > <xs:restriction base="xs:string"> > <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/> > </xs:restriction> > </xs:simpleType> > </xs:attribute> > </xs:complexType> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > .... > .... > <xs:key name="ATTRIBUTE"> > <xs:selector xpath="Attributes/Attribute"/> > <xs:field xpath="@id"/> > </xs:key> > <xs:keyref name="X001" refer="ATTRIBUTE"> > <xs:selector xpath="Indexes/Tag"/> > <xs:field xpath="@attribute_id"/> > </xs:keyref> > .... > > > Thanks: > Bence > -- > View this message in context: > http://www.nabble.com/XML-schema-tp25945562p25945562.html > Sent from the w3.org - xmlschema-dev mailing list archive at > Nabble.com. > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304973.html Hi I have an xml schema which restricts the Indexes/Tag/@attribute_id values to the ones are defined in the parent element's Attributes/Attribute/@id. Is there a way to extend this and enable one (or more) different static values for example "id"? There are more Indexes/Tag and Attributes/Attribute tags and i would like to use this restriction only for thoose that has the same parent. Here is my current configuration: .... <xs:element name="Attributes"> <xs:complexType> <xs:sequence> <xs:element name="Attribute" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="Attribute_Type"> <xs:attribute name="typedef_id" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> .... <xs:element name="Indexes" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="attribute_id" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> .... .... <xs:key name="ATTRIBUTE"> <xs:selector xpath="Attributes/Attribute"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref name="X001" refer="ATTRIBUTE"> <xs:selector xpath="Indexes/Tag"/> <xs:field xpath="@attribute_id"/> </xs:keyref> .... Thanks: Bence -- View this message in context: http://www.nabble.com/XML-schema-tp25945562p25945562.html Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304972.html Michael Kay writes: > Perhaps you just let it be caught by the general ban on duplicate > components. That was the idea. > But unless you're careful about the wording, that ban also > catches you out on a linear chain of redefinitions. I'm pretty sure that's handled OK. Specifically, the text that says: "Check for duplicate names (I.e. two or more definitions among the union of components and prototype components of the same global name in the same symbol set) and reflect a violation of the appropriate constraint if found. Note that redeclaration-prototypes need not be checked for duplicates, as each necessarily redefines a similarly named prototype-component. " At this stage of the processing, the redeclarations are all tracked in a set of redeclaration-prototypes, which is not set that's being checked for duplicate names in the same symbol space. Once this check for duplicates is passed, then the redefinitions are processed. > If there's a cycle in the graph of schema documents then > there's potential (but not the necessity) of a cycle at the > level of components. A cycle at the > component level is clearly a nonsense, and my inclination is > that the same is true at the document level. I think I had convinced myself that there could not be a cycle at the document level, but I'm not remembering why I came to that conclusion. Certainly the set-of-named-documents approach ACSOOD takes to includes and imports means that cycles aren't treated as a problem, but are handled. If A.xsd and B.xsd mutually include each other, then each is added to the set once (it's a set, so there's no other option) and processed. As to redefine, if A.xsd redefines T in B.xsd, and B.xsd redefines T in A.xsd, then I THINK the same text you newly discovered forces an error. There MUST be an explicit top level declaration for T in both A.xsd and B.xsd, or the clause you cite triggers failure. If there are explicit top level declarations, then the ACSOOD "check for duplicate names" clause quoted above triggers a different error. So, I think redefine cycles are ruled out by ACSOOD, and probably by most reasonable readings of the text you discovered. > That's precisely what I do in my implementation. Well, I have the general sense that ACSOOD and your implementation are very much the same in spirit, if not in every detail. I suppose that's promising in some way or other, but I'm not clear on how it helps us move ahead this point. At the very least, it's somewhat gratifying to me personally. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Michael Kay" <mike@saxonica.com> 10/16/2009 05:22 PM To: <noah_mendelsohn@us.ibm.com> cc: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org> Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: 16 October 2009 21:35 > To: Michael Kay > Cc: 'Henry S. Thompson'; 'XMLSchema at XML4Pharma'; > xmlschema-dev@w3.org > Subject: RE: Escalation mechanism for different > interpretation of W3C XML-Schema specification ? > > Michal Kay writes; > > > It's not clear what answers it gives for more complex redefinition > > graphs. > > Well, it's been a long time since I've looked at it. I guess > I assume that all redefinition graphs are in fact trees, I.e. > each redefine can redefine only one thing Well, there's a graph of schema documents, and a graph of components. If there's a cycle in the graph of schema documents then there's potential (but not the necessity) of a cycle at the level of components. A cycle at the component level is clearly a nonsense, and my inclination is that the same is true at the document level. Even without cycles, though, it's not clear to me how ACSOOD handles: A includes B A includes C B redefines X defining a restriction of type T C redefines X defining a (different) restriction of type T Perhaps you just let it be caught by the general ban on duplicate components. But unless you're careful about the wording, that ban also catches you out on a linear chain of redefinitions. I noted the statement in your proposal: "Note that the information needed to determine a redeclaration prototype is easily determined from the <redefine>ing XML schema document; the text of a redeclaration always explicitly refers to the particular schema document containing (specification of) the component being redefined. " I was surprised to see this, but I now see that the spec does say (in Schema Representation Constraint: Individual Component Redefinition) "In all cases there must be a top-level definition item of the appropriate name and kind in the <redefine>d schema document." I now realise I haven't been enforcing that rule: I only require it to be present in "the schema corresponding to" the <redefine>d schema document. If A includes B, and R redefines A, then I allow R to contain redefinitions of components that are actually defined in schema document B. And the Dutch schema I've been working on today (http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd) certainly takes advantage of that freedom. > > > And it doesn't appear to have anything to say about > chameleon include. > > ... I think this probably means that I would have to augment my > list of schema document abstraction to actually make it a > list of (schemadoc, targetNamespace) pairs, That's precisely what I do in my implementation. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304962.html > -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: 16 October 2009 21:35 > To: Michael Kay > Cc: 'Henry S. Thompson'; 'XMLSchema at XML4Pharma'; > xmlschema-dev@w3.org > Subject: RE: Escalation mechanism for different > interpretation of W3C XML-Schema specification ? > > Michal Kay writes; > > > It's not clear what answers it gives for more complex redefinition > > graphs. > > Well, it's been a long time since I've looked at it. I guess > I assume that all redefinition graphs are in fact trees, I.e. > each redefine can redefine only one thing Well, there's a graph of schema documents, and a graph of components. If there's a cycle in the graph of schema documents then there's potential (but not the necessity) of a cycle at the level of components. A cycle at the component level is clearly a nonsense, and my inclination is that the same is true at the document level. Even without cycles, though, it's not clear to me how ACSOOD handles: A includes B A includes C B redefines X defining a restriction of type T C redefines X defining a (different) restriction of type T Perhaps you just let it be caught by the general ban on duplicate components. But unless you're careful about the wording, that ban also catches you out on a linear chain of redefinitions. I noted the statement in your proposal: "Note that the information needed to determine a redeclaration prototype is easily determined from the <redefine>ing XML schema document; the text of a redeclaration always explicitly refers to the particular schema document containing (specification of) the component being redefined. " I was surprised to see this, but I now see that the spec does say (in Schema Representation Constraint: Individual Component Redefinition) "In all cases there must be a top-level definition item of the appropriate name and kind in the <redefine>d schema document." I now realise I haven't been enforcing that rule: I only require it to be present in "the schema corresponding to" the <redefine>d schema document. If A includes B, and R redefines A, then I allow R to contain redefinitions of components that are actually defined in schema document B. And the Dutch schema I've been working on today (http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd) certainly takes advantage of that freedom. > > > And it doesn't appear to have anything to say about > chameleon include. > > ... I think this probably means that I would have to augment my > list of schema document abstraction to actually make it a > list of (schemadoc, targetNamespace) pairs, That's precisely what I do in my implementation. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304961.html Michal Kay writes; > It's not clear what answers it gives for more complex > redefinition graphs. Well, it's been a long time since I've looked at it. I guess I assume that all redefinition graphs are in fact trees, I.e. each redefine can redefine only one thing, and ultimately there is a path back up to the collection of the coponents you would have had if no redefinitions at all were done. What I believe ACSOOD tries to do is, first collect all of the prototype components that are not themselves the result of redefines, then apply the redefinitions recursively, with each one being pervasive. Is there a particular sample you have in mind for which ACSOOD doesn't signal a fairly clear direction? You may well be right, but I'd be very curious to learn what it is. > And it doesn't appear to have anything to say about chameleon include. I went back and looked at it. You're right that it isn't dealt with explicitly. My suggestion would be that it be handled locally to the preparation of prototype components of each include step. Thus, if a schema with target namespace N included a schema doc with no explicit target NS, it would for ACSOOD purposes be as if the included document did have an explicit targetNamespace="N". If that same document were included in another context, then that would be handled as a completely separate include, with the same rule applied. I think this probably means that I would have to augment my list of schema document abstraction to actually make it a list of (schemadoc, targetNamespace) pairs, where in most cases the targetNamespace would be determined trivially from the schemadoc's attribute, but in the case of chameleon would be taken from the include statement. This would allow the same schemadoc to be included in the list repeatedly, once for each targetNS. Again, ACSOOD was an attempt to set down more crisply how I always thought the whole thing was working right along, though I later came to understand some of the ambiguities in the spec as written, and that other people have interpreted it differently. I also am a little unhappy with the fact that ACSOOD depends in its current form on identify of schema documents (it has a set of them), which raises some nasty questions about cases in which schemaLocation URIs differ in, e.g., upper/lowercase, but in ways that we know won't affect the referent (e.g. http://xxx vs. HTTP://xxx) ACSOOD more or less winds up treating these as distinct documents, potentially including them separately, and quite likely resulting in duplicate component errors. Otherwise, I think it's in the ballpark. Then again, I said as much in 2004, and it was clear that there were many differing opinions in the WG as to how things really work in 1.0, how they should work in 1.1, and especially in how to explain how they should work in 1.1. I really don't want to reopen all of that here. I'm just pointing to ACSOOD is a simple way of indicating what my personal assumptions have been about how redefine should work. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Michael Kay" <mike@saxonica.com> 10/16/2009 04:11 PM To: <noah_mendelsohn@us.ibm.com> cc: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org> Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > While my > ACSOOD proposal remains very incomplete and has a variety of > problems, I think it does more or less signal my thinking > about questions like this [1]. > Yes. It's close the the way I think about it. It appears to handle a chain of redefinition (A redefines B, B redefines C) in the same way as I do. It's not clear what answers it gives for more complex redefinition graphs. And it doesn't appear to have anything to say about chameleon include. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304956.html > While my > ACSOOD proposal remains very incomplete and has a variety of > problems, I think it does more or less signal my thinking > about questions like this [1]. > Yes. It's close the the way I think about it. It appears to handle a chain of redefinition (A redefines B, B redefines C) in the same way as I do. It's not clear what answers it gives for more complex redefinition graphs. And it doesn't appear to have anything to say about chameleon include. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304955.html Michael Kay writes: > Because the common components have been copied into three different > namespaces, a redefine occurring in one namespace does not > affect copies of > the component in a different namespace. That's Saxon's interpretation, > anyway. You could take the view that the "pervasiveness" of redefinition > makes it transcend the renaming done by the chameleon include, > but I don't. FWIW, I don't either. More specifically, if you'd asked me not about the text of the Recommendation as it came out (which I think we've established is somewhat self-contradictory and thus interpreted differently by different readers), but about what I thought we were trying to say as we all wrote that, I agree with you. While my ACSOOD proposal remains very incomplete and has a variety of problems, I think it does more or less signal my thinking about questions like this [1]. BTW: this proposal gets referenced from time to time, and as far as I can tell the only copy remains in member-only space. If there's a way to do it without inconveniencing the chair or working group members, I will try to get permission post another public copy, perhaps in the W3C public archives. I think it's useful for references like this to be public when practical. (I am not proposing to start active discussion of it now, but every few years an email thread like this pops up, and I find it inconvenient to have links that can't be read outside of W3C. I'll ask on the working group's list, which is the right place to do it. In the meantime, apologies to readers outside the WG who can't see it. FYI, we were (in 2004!) making a major effort to clarify the composition story for XSD 1.1. The paper reference at [1] was an experimental attempt by me to create a design that would capture what I thought we intended in XSD 1.0. I think there are some good ideas in it, but it's also incomplete and has a number of problems. Other important proposals were made by other working group members, many months were spent trying to extract from all of this a story that would garner consensus as a better explanation than the one we had in XSD 1.0, and to a signficant degree we failed. So, I refer to this only because with respect to issues like the ones Mike raises, some of my thinking is captured in more detail at [1]. Noah [1] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Jul/att-0004/CompositionArchitecture.html -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Michael Kay" <mike@saxonica.com> Sent by: xmlschema-dev-request@w3.org 10/16/2009 09:29 AM To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk> cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > Hmmm -- let's leave redefine aside, as we've agreed to differ > on that before, but I'm surprised you recommend against > chameleon include. I find it hugely useful (for those little > bits that you use all the time but aren't worth putting in a > namespace) and am not aware of any interop problems with it. . . I've been working on a bug report relating to a Dutch government schema published at http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd which makes extensive use of redefines and chameleon include. I've fixed the bug that stopped this working under Saxon 9.2, but I would make some observations on the schema, which are I think rather pertinent to this thread. There's a cluster of three no-namespace schema documents (overheid-types, overheid-classes, overheid-schemes) that are chameleon-included into three different namespaces (short names /vac/, /dc/terms/, and /owms/terms/). The effect of this is to create three near-identical copies of each of the components defined in these three schema documents, one in each namespace. This means that as far as XSLT and XQuery are concerned, elements/attributes defined in terms of these types will be unrelated to each other in the type hierarchy, which means that writing schema-aware stylesheets and queries is likely to be very confusing. This is probably one of the main reasons I'm not a fan of chameleon include. But that's not all: the schema also makes heavy use of redefines. Specifically, if we call this no-namespace cluster COMMON, we have the structure (slightly simplified to capture the essence): Namespace /vac/ vac.xsd includes COMMON vac.xsd imports owms-classes-redef.xsd vac.xsd imports overheid-classes-redef.xsd Namespace /dc/terms/ owms-classes-redef.xsd redefines dcterms-elem.xsd dcterms-elem.xsd includes COMMON Namespace /owms/terms/ overheid-classes-redef.xsd redefines owns.xsd owms.xsd includes COMMON owms.xsd imports dcterms-elem.xsd Note that dcterms-elem.xsd is reachable from vac.xsd via one route that contain a "redefines" step, and by another route that omits this step (but which does contain a different redefines step). This is where the interpretation of "pervasiveness" is critical: Saxon takes the view that all references to components that have been redefined are references to the post-redefinition component. In fact the rule introduced in Saxon 9.2 (whose incorrect implementation caused the bug) is that every component has a redefinition level, so if A redefines B and B redefines C then a given component may have redefinition levels of 2, 1, and 0; all references to a component name are taken as references to the highest available redefinition level, and if there are two different components at the highest redefinition level, it's an error (for example, A redefines C, and B also redefines C). There's nothing at all in the spec to justify these rules, but it's the only way I could find of handling complex redefinition lattices that seemed to make sense. But the chameleon includes interfere with this (perhaps deliberately). Because the common components have been copied into three different namespaces, a redefine occurring in one namespace does not affect copies of the component in a different namespace. That's Saxon's interpretation, anyway. You could take the view that the "pervasiveness" of redefinition makes it transcend the renaming done by the chameleon include, but I don't. In experimenting further with this schema, I discovered that if the two imports from vac.xsd are reversed in order, the import of owms-classes-redef.xsd has no effect, because it is then importing a namespace that is already known to the processor; Saxon ignores the schemaLocation URI in this case. So the schema document owms-classes-redef.xsd, and the redefinitions that it contains, are simply ignored. This makes the situation very fragile: reversing the order of imports does not make the processing fail, it just silently compiles a different schema. I think this reinforces Henry's argument that if you're going to redefine, then there should be one redefining document for each namespace, which acts as a gateway to that namespace, and no other includes/imports/redefines from elsewhere in the schema should bypass this gateway. This schema breaks this rule, and gets away with it only because of gateway document is encountered before the bypassing document. Michael Kay Saxonica]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304954.html > Hmmm -- let's leave redefine aside, as we've agreed to differ > on that before, but I'm surprised you recommend against > chameleon include. I find it hugely useful (for those little > bits that you use all the time but aren't worth putting in a > namespace) and am not aware of any interop problems with it. . . I've been working on a bug report relating to a Dutch government schema published at http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd which makes extensive use of redefines and chameleon include. I've fixed the bug that stopped this working under Saxon 9.2, but I would make some observations on the schema, which are I think rather pertinent to this thread. There's a cluster of three no-namespace schema documents (overheid-types, overheid-classes, overheid-schemes) that are chameleon-included into three different namespaces (short names /vac/, /dc/terms/, and /owms/terms/). The effect of this is to create three near-identical copies of each of the components defined in these three schema documents, one in each namespace. This means that as far as XSLT and XQuery are concerned, elements/attributes defined in terms of these types will be unrelated to each other in the type hierarchy, which means that writing schema-aware stylesheets and queries is likely to be very confusing. This is probably one of the main reasons I'm not a fan of chameleon include. But that's not all: the schema also makes heavy use of redefines. Specifically, if we call this no-namespace cluster COMMON, we have the structure (slightly simplified to capture the essence): Namespace /vac/ vac.xsd includes COMMON vac.xsd imports owms-classes-redef.xsd vac.xsd imports overheid-classes-redef.xsd Namespace /dc/terms/ owms-classes-redef.xsd redefines dcterms-elem.xsd dcterms-elem.xsd includes COMMON Namespace /owms/terms/ overheid-classes-redef.xsd redefines owns.xsd owms.xsd includes COMMON owms.xsd imports dcterms-elem.xsd Note that dcterms-elem.xsd is reachable from vac.xsd via one route that contain a "redefines" step, and by another route that omits this step (but which does contain a different redefines step). This is where the interpretation of "pervasiveness" is critical: Saxon takes the view that all references to components that have been redefined are references to the post-redefinition component. In fact the rule introduced in Saxon 9.2 (whose incorrect implementation caused the bug) is that every component has a redefinition level, so if A redefines B and B redefines C then a given component may have redefinition levels of 2, 1, and 0; all references to a component name are taken as references to the highest available redefinition level, and if there are two different components at the highest redefinition level, it's an error (for example, A redefines C, and B also redefines C). There's nothing at all in the spec to justify these rules, but it's the only way I could find of handling complex redefinition lattices that seemed to make sense. But the chameleon includes interfere with this (perhaps deliberately). Because the common components have been copied into three different namespaces, a redefine occurring in one namespace does not affect copies of the component in a different namespace. That's Saxon's interpretation, anyway. You could take the view that the "pervasiveness" of redefinition makes it transcend the renaming done by the chameleon include, but I don't. In experimenting further with this schema, I discovered that if the two imports from vac.xsd are reversed in order, the import of owms-classes-redef.xsd has no effect, because it is then importing a namespace that is already known to the processor; Saxon ignores the schemaLocation URI in this case. So the schema document owms-classes-redef.xsd, and the redefinitions that it contains, are simply ignored. This makes the situation very fragile: reversing the order of imports does not make the processing fail, it just silently compiles a different schema. I think this reinforces Henry's argument that if you're going to redefine, then there should be one redefining document for each namespace, which acts as a gateway to that namespace, and no other includes/imports/redefines from elsewhere in the schema should bypass this gateway. This schema breaks this rule, and gets away with it only because of gateway document is encountered before the bypassing document. Michael Kay Saxonica]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304951.html On 12 Oct 2009, at 11:00 , Costello, Roger L. wrote: > > Hi Folks, > > Below are two ways to declare a <Book> element. > > Both versions use <all>, to permit the elements within <Book> to > occur in any order. > > The first version uses an unbounded <any>. The second version uses > interleaved open content. > > Are these two versions identical? You may mean "Do they accept the same inputs as valid instances of element Book?" Yes, I think they do. > If so, is there an advantage of one over the other? Some people may find one formulation clearer or simpler than the other; they will rightly prefer the one they find clearer. I expect different people will have different preferences, depending on their tastes. If a schema is designed so that ever complex type, or most of them, has a particular form of open content, then the open content can be defaulted at the schema document level, which will make most content models shorter and simpler. Readers who forget that the schema document supplies default open content may be surprised and complain about action at a distance. In the case of all-groups, using an explicit wildcard and using interleave open content are roughly similar in complexity of the declaration. In other cases, explicit wildcards are much more verbose and for many schema authors rather error-prone. See http://www.w3.org/TR/xmlschema-guide2versioning/ for examples. > If they are not identical, how do they differ? You may mean "Do they produce indistinguishable PSVIs?" No, not quite; the [match information] property in the PSVI allows the two to be distinguished, for elements other than Author, Title, Date, ISBN, and Publisher: in the one case, those elements will have [match information] = 'lax' (since they match a lax wildcard in the content model), and in the other they will have [match information] = 'open' (since they match open content). This allows the downstream application to distinguish the two cases, if it wishes to. In the usual case, making downstream processing depend on such a subtle distinction is probably not a good idea, but YMMV and there may be special circumstances. Certainly there are some designers who like the idea of being able to say that if an element in the input matches an element in the version N content model, then a version N processor is obligated to process it in a certain way, and if the element in the input matches a wildcard (or: matches only open content) in the version N content model, then a version N processor is obligated to tolerate it, or to ignore it, or to handle it in some other way. In such a design, "matches an element" and "matches a wildcard" are syntax-level signals for different kinds of processing. The signal "matches an open-content wildcard" can fit nicely into this pattern, either to signal a third kind of processing or to shift the distinction from element-vs-wildcard to content-model-vs-opencontent. HTH -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304871.html > Hmmm -- let's leave redefine aside, as we've agreed to differ > on that before, but I'm surprised you recommend against > chameleon include. I find it hugely useful (for those little > bits that you use all the time but aren't worth putting in a > namespace) and am not aware of any interop problems with it. . . Well, it's partly that if you allow the same data to be in different namespaces at different times then it's much harder to write reusable code in XSLT/XQuery etc that works regardless of which namespace has been chosen today. But it certainly can lead to problems of interpretation: (a) problems hinging on the (XSD 1.0) phrase "corresponds to a <schema> element information item in a well-formed information set, which in turn corresponds to a valid schema." - the correspondence of the schema information item to the valid schema is never spelt out, so it's not clear for example if A does a chameleon include on B which imports C which imports the no-namespace schema document D, whether components defined in D are moved into the target namespace of A; especially if C or D are also reachable by other routes. (b) problems hinging on exactly where the substitution of targetNamespace applies, for example, whether it affects XPath expressions in identity constraints, QNames used in enumeration facets, or references to no-namespace components defined in a schema document that is not itself within the scope of the chameleon include. We've improved the rules for XSD 1.1, but it's still a facility I would be inclined to avoid. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304861.html Hi Folks, Below are two ways to declare a <Book> element. Both versions use <all>, to permit the elements within <Book> to occur in any order. The first version uses an unbounded <any>. The second version uses interleaved open content. Are these two versions identical? If so, is there an advantage of one over the other? If they are not identical, how do they differ? /Roger VERSION #1 <xs:element name="Book"> <xs:complexType> <xs:all> <xs:any maxOccurs="unbounded" /> <xs:element name="Author" type="xs:string" /> <xs:element name="Title" type="xs:string" /> <xs:element name="Date" type="xs:string" /> <xs:element name="ISBN" type="xs:string"/> <xs:element name="Publisher" type="xs:string" /> </xs:all> </xs:complexType> </xs:element> VERSION #2 <xs:element name="Book"> <xs:complexType> <xs:openContent mode="interleave"> <xs:any /> </xs:openContent> <xs:all> <xs:element name="Title" type="xs:string"/> <xs:element name="Author" type="xs:string" /> <xs:element name="Date" type="xs:string"/> <xs:element name="ISBN" type="xs:string"/> <xs:element name="Publisher" type="xs:string"/> </xs:all> </xs:complexType> </xs:element>]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304854.html I agree with all of this, but it leaves the question of xs:redefine. I suspect, but without testing(!) that the strategy can be extended to xs:redefine as follows: (a) if redefinition for a namespace is required, create a new schema document with that targetNamespace that invokes the (previous) primary schema document for that namespace using xs:redefine, and contains all the redefinitions needed. (b) change the driver document to refer to the redefinition documents introduced in step (1) in place of the (previous) primary shcema documents. A similar approach might also work reliably for "chameleon include". But better advice is not to use redefine or chameleon include. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of Henry S. Thompson > Sent: 12 October 2009 16:40 > To: XMLSchema at XML4Pharma > Cc: xmlschema-dev@w3.org > Subject: Re: Escalation mechanism for different > interpretation of W3C XML-Schema specification ? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stimulated in equal measure by this thread, and a request > from the XML Security WG [0], I came up with my personal > 'best practice' guideline for schema document design for > multi-namespace schemas. I include the core bit below -- for > the full context and a worked example, see my reply to the > DSIG WG [1]. > > ht > > [0] > http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0019.html > [1] > http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0023.html > - ------------------------- > HST's best practice guide for multiple-namespace schema composition > > It's helpful in discussions of this sort to be careful with > vocabulary: > > Schema document: An XML document in the W3C XML Schema namespace > Schema: An abstract data object, typically composed from one or more > schema documents according to the rules given in the W3C XML > Schema specs. > > A schema document specifies either one or no target namespace. > > A schema may well contain element & attribute declarations > and/or type definitions for many target namespaces. > > The W3C XML Schema specs provide a number of mechanisms for > assembling the schema documents needed to construct a schema > for a particular validation episode: > > 1) the schemaLocation attribute on xs:include elements. > 2) xsi:schemaLocation (in the instance to be validated); > 3) the schemaLocation attribute on xs:import elements; > 4) the namespace URIs themselves (in the instance to be validated, or > from the namespace attribute on xs:import elements); > > Without going into the details of what's optional and what's > required, or of the range of choices implementations exhibit, > here's my recommendation for multi-namespace schemas: > > 1) For each namespace in your language, there should be one primary > schema document. It may be the only schema document for that > namespace, or it may use xs:include (which must have a > schemaLocation attribute) to allow for modular development by > including multiple as-it-were secondary schema documents; > > 2) Whenever reference is made to names in another namespace from a > primary or secondary schema document, use an xs:import _without_ a > schemaLocation attribute; > > 3) Create a driver schema document, whose target namespace is the > namespace of the (most common) document element of instance > documents in the language. It should contain an xs:include of the > primary schema document for that namespace, and xs:imports for all > the other namespaces, _with_ schemaLocation attributes pointing to > the primary schema documents for those other namespaces. > > Then, by passing the location of the driver schema document > to schema validation tools and/or by including an > xsi:schemaLocation attribute on the document element of > instances to be validated which associates the target > namespace of the driver schema document with its location, > you will get the behaviour you need from all the > tools/implementations I am aware of. > > Schematically, this looks like > > driver.xsd -- TNS = http://www.example.org/rootNS > /|> / | > / | > / | > xs:include | > schemaLoc= | > / | > / xs:import > / NS=...NS2 > / schemaLoc= > / | xs:import > / | NS=...NS3 > / | schemaLoc= > / | > primary1.xsd primary2.xsd primary3.xsd > TNS=...rootNS TNS=...NS2 TNS=...NS3 > / \ /|> / \ / | > / \ / | > / \ / | > xs:import xs:import / | > NS=...NS2 NS=...NS3 xs:include | > schemaLoc= | > / | > 3.1.xsd | > xs:include > schemaLoc= > | > 3.2.xsd > xs:include > schemaLoc= > | > 3.3.xsd > > - -- > Henry S. Thompson, School of Informatics, University > of Edinburgh > Half-time member of W3C Team > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) > 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without > it is forged spam] -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFK0021kjnJixAXWBoRAmPMAJ9dLLKZsj+r2y/tUtIsJ/wAjuL0kQCfWwzT > LqnqG7FgzH5zwP3XMIrNsb4= > =vK80 > -----END PGP SIGNATURE----- >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304851.html -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stimulated in equal measure by this thread, and a request from the XML Security WG [0], I came up with my personal 'best practice' guideline for schema document design for multi-namespace schemas. I include the core bit below -- for the full context and a worked example, see my reply to the DSIG WG [1]. ht [0] http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0019.html [1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0023.html - ------------------------- HST's best practice guide for multiple-namespace schema composition It's helpful in discussions of this sort to be careful with vocabulary: Schema document: An XML document in the W3C XML Schema namespace Schema: An abstract data object, typically composed from one or more schema documents according to the rules given in the W3C XML Schema specs. A schema document specifies either one or no target namespace. A schema may well contain element & attribute declarations and/or type definitions for many target namespaces. The W3C XML Schema specs provide a number of mechanisms for assembling the schema documents needed to construct a schema for a particular validation episode: 1) the schemaLocation attribute on xs:include elements. 2) xsi:schemaLocation (in the instance to be validated); 3) the schemaLocation attribute on xs:import elements; 4) the namespace URIs themselves (in the instance to be validated, or from the namespace attribute on xs:import elements); Without going into the details of what's optional and what's required, or of the range of choices implementations exhibit, here's my recommendation for multi-namespace schemas: 1) For each namespace in your language, there should be one primary schema document. It may be the only schema document for that namespace, or it may use xs:include (which must have a schemaLocation attribute) to allow for modular development by including multiple as-it-were secondary schema documents; 2) Whenever reference is made to names in another namespace from a primary or secondary schema document, use an xs:import _without_ a schemaLocation attribute; 3) Create a driver schema document, whose target namespace is the namespace of the (most common) document element of instance documents in the language. It should contain an xs:include of the primary schema document for that namespace, and xs:imports for all the other namespaces, _with_ schemaLocation attributes pointing to the primary schema documents for those other namespaces. Then, by passing the location of the driver schema document to schema validation tools and/or by including an xsi:schemaLocation attribute on the document element of instances to be validated which associates the target namespace of the driver schema document with its location, you will get the behaviour you need from all the tools/implementations I am aware of. Schematically, this looks like driver.xsd -- TNS = http://www.example.org/rootNS /| / | / | / | xs:include | schemaLoc= | / | / xs:import / NS=...NS2 / schemaLoc= / | xs:import / | NS=...NS3 / | schemaLoc= / | primary1.xsd primary2.xsd primary3.xsd TNS=...rootNS TNS=...NS2 TNS=...NS3 / \ /| / \ / | / \ / | / \ / | xs:import xs:import / | NS=...NS2 NS=...NS3 xs:include | schemaLoc= | / | 3.1.xsd | xs:include schemaLoc= | 3.2.xsd xs:include schemaLoc= | 3.3.xsd - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFK0021kjnJixAXWBoRAmPMAJ9dLLKZsj+r2y/tUtIsJ/wAjuL0kQCfWwzT LqnqG7FgzH5zwP3XMIrNsb4= =vK80 -----END PGP SIGNATURE-----]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304847.html Hi Pete, Good point. That sounds like a good idea. Cheers for that, Andy -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Pete Cordell Sent: 09 October 2009 10:03 To: Neill, Andrew Cc: xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, In that case it might be more aesthetic to move the minOccurs to the outer xsd:choice so you get: <xsd:choice minOccurs="0" maxOccurs="unbounded"> Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com> Cc: <xmlschema-dev@w3.org> Sent: Friday, October 09, 2009 9:35 AM Subject: RE: xsd ambigious Hi Pete, Thanks for that but I thought about it and although I wanted d to appear before e or f, it is possible to submit an xml file with none of these fields populated so I left it in there. Cheers, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 09 October 2009 09:33 To: Neill, Andrew Cc: xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, That's great. Actually, I don't know whether you noticed already, but looking at it again, I don't think the minOccurs="0" on the xsd:sequence is required. HTH, Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org> Sent: Thursday, October 08, 2009 11:11 AM Subject: RE: xsd ambigious Hi Pete, That works. I don't know how I missed that. Many Thanks, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 08 October 2009 11:07 To: Neill, Andrew; xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304647.html Hi Andy, In that case it might be more aesthetic to move the minOccurs to the outer xsd:choice so you get: <xsd:choice minOccurs="0" maxOccurs="unbounded"> Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com> Cc: <xmlschema-dev@w3.org> Sent: Friday, October 09, 2009 9:35 AM Subject: RE: xsd ambigious Hi Pete, Thanks for that but I thought about it and although I wanted d to appear before e or f, it is possible to submit an xml file with none of these fields populated so I left it in there. Cheers, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 09 October 2009 09:33 To: Neill, Andrew Cc: xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, That's great. Actually, I don't know whether you noticed already, but looking at it again, I don't think the minOccurs="0" on the xsd:sequence is required. HTH, Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org> Sent: Thursday, October 08, 2009 11:11 AM Subject: RE: xsd ambigious Hi Pete, That works. I don't know how I missed that. Many Thanks, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 08 October 2009 11:07 To: Neill, Andrew; xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304646.html Hi Pete, Thanks for that but I thought about it and although I wanted d to appear before e or f, it is possible to submit an xml file with none of these fields populated so I left it in there. Cheers, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 09 October 2009 09:33 To: Neill, Andrew Cc: xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, That's great. Actually, I don't know whether you noticed already, but looking at it again, I don't think the minOccurs="0" on the xsd:sequence is required. HTH, Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org> Sent: Thursday, October 08, 2009 11:11 AM Subject: RE: xsd ambigious Hi Pete, That works. I don't know how I missed that. Many Thanks, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 08 October 2009 11:07 To: Neill, Andrew; xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304641.html Hi Andy, That's great. Actually, I don't know whether you noticed already, but looking at it again, I don't think the minOccurs="0" on the xsd:sequence is required. HTH, Pete. ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org> Sent: Thursday, October 08, 2009 11:11 AM Subject: RE: xsd ambigious Hi Pete, That works. I don't know how I missed that. Many Thanks, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 08 October 2009 11:07 To: Neill, Andrew; xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304640.html Excellent, thanks! On 10/6/2009 6:40 PM, C. M. Sperberg-McQueen wrote: > > On 6 Oct 2009, at 14:45 , Kevin Braun wrote: > >> Hello, >> >> >> Can anyone explain the following comment from the "changes since" in >> XSD 1.1? >> >> "When an |xsi:type| attribute appears on an element, and has a QName >> as its value, but the QName does not resolve to a known type >> definition, processors are now required to "fall back" to lax >> validation, using the declared {type >> <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition> >> definition} <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition> >> of the ·governing element declaration· >> <http://www.w3.org/TR/xmlschema11-1/#key-governing-ed> as the >> ·governing type definition· >> <http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem>." >> >> >> >> First, I believe that lax validation is by definition against >> xs:anyType, so I'm not sure what it means to do lax validation using >> some other type. > > You're right; the description should not use the term 'lax > validation'. The new rule is an attempt to define more > useful fallback behavior than fallback to lax validation. > >> >> Second, such a case as is being described violates rule 4 of Element >> Locally Valid (Element) (§3.3.4.3) >> <http://www.w3.org/TR/xmlschema11-1/#cvc-elt> (the instance-specified >> type definition would be absent), > > Correct. So the element is not marked valid. > >> and I don't see where there is any exception made to it. There is >> some verbiage (in §3.3.4.3) about what happens to the governing type >> declaration in this case, but I don't think this verbiage is giving >> an exception to rule 4 (I assume it is summarizing the application of >> the definition of "governing type declaration"). > > Clause 5 of the validation rule says that the element is to be validated > against its governing type definition. This doesn't constitute an > exception to clause 4. Validating the element against the declared > type, rather than xsd:anyType, can be helpful when the downstream > processor > wishes to recover from the missing component and when the declared type > has some local element declarations which would not be found by > validating > the element against xsd:anyType. > > >> Schema-Validity Assessment (Element) (§3.3.4.6) >> <http://www.w3.org/TR/xmlschema11-1/#cvc-assess-elt> does give a >> requirement for lax assessment according to xs:anyType, but I don't >> think it applies here because the situation described doesn't prevent >> assessment - it just has "invalid" as the outcome. Besides that, the >> type to use for the lax assessment doesn't agree with the statement I >> quoted. >> >> So, in short, I don't know what to make of the above statement. > > I hope the comments above help clarify things. > >> Can anyone point me to where the "fall back" requirement can be found? > > > I'm not sure whether you mean "what user requirement does this > serve?" (answer: better behavior in the case of missing > components), or "why does the change list say that the > processor falls back to the declared type?" (answer: because > clause 5 of Element Locally Valid (Element) says to validate > the element against its governing type definition, and the > definition of governing type definition says that if the > instance-specified type does not successfully override the > selected or declared type [which will be the case if the > value of the xsi:type attribute fails to resolve], then the > element's declared type will be the governing type). > > HTH >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304584.html Hi George, Thanks for that. I have been looking at this schema too long and missed that. Thanks for your help. Andy -----Original Message----- From: George Cristian Bina [mailto:george@oxygenxml.com] Sent: 08 October 2009 11:07 To: Neill, Andrew Cc: xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, You can have a first any of a, b, c any number of times and then follow them optionally with d followed by any of a, b, c, e, f any number of times: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:sequence> <xsd:choice maxOccurs="unbounded" minOccurs="0"> <xsd:element ref="a"/> <xsd:element ref="b"/> <xsd:element ref="c"/> </xsd:choice> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice maxOccurs="unbounded" minOccurs="0"> <xsd:element ref="a"/> <xsd:element ref="b"/> <xsd:element ref="c"/> <xsd:element ref="e"/> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com Neill, Andrew wrote: > Can anyone help with this XSD please? It doesnt seem to work? > Essentially i want to ensure that if "E" or "F" are populated then "D" > is populated before them. The rest of the elements can appear in any > order and any amount of times. > > <?xml version="1.0" encoding="UTF-8"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="element"> > <xsd:complexType> > <xsd:choice maxOccurs="unbounded"> > <xsd:element ref="a" minOccurs="0"/> > <xsd:element ref="b" minOccurs="0"/> > <xsd:element ref="c" minOccurs="0"/> > <xsd:sequence> > <xsd:element ref="d"/> > <xsd:element ref="e"/> > </xsd:sequence> > <xsd:sequence> > <xsd:element ref="d"/> > <xsd:element ref="f"/> > </xsd:sequence> > </xsd:choice> > </xsd:complexType> > </xsd:element> > <xsd:element name="a"/> > <xsd:element name="b"/> > <xsd:element name="c"/> > <xsd:element name="d"/> > <xsd:element name="e"/> > <xsd:element name="f"/> > </xsd:schema> > > Many Thanks, > Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304571.html Hi Pete, That works. I don't know how I missed that. Many Thanks, Andy -----Original Message----- From: Pete Cordell [mailto:petexmldev@codalogic.com] Sent: 08 October 2009 11:07 To: Neill, Andrew; xmlschema-dev@w3.org Subject: Re: xsd ambigious Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304570.html Hi Andy, You can have a first any of a, b, c any number of times and then follow them optionally with d followed by any of a, b, c, e, f any number of times: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:sequence> <xsd:choice maxOccurs="unbounded" minOccurs="0"> <xsd:element ref="a"/> <xsd:element ref="b"/> <xsd:element ref="c"/> </xsd:choice> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice maxOccurs="unbounded" minOccurs="0"> <xsd:element ref="a"/> <xsd:element ref="b"/> <xsd:element ref="c"/> <xsd:element ref="e"/> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com Neill, Andrew wrote: > Can anyone help with this XSD please? It doesnt seem to work? > Essentially i want to ensure that if "E" or "F" are populated then "D" > is populated before them. The rest of the elements can appear in any > order and any amount of times. > > <?xml version="1.0" encoding="UTF-8"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="element"> > <xsd:complexType> > <xsd:choice maxOccurs="unbounded"> > <xsd:element ref="a" minOccurs="0"/> > <xsd:element ref="b" minOccurs="0"/> > <xsd:element ref="c" minOccurs="0"/> > <xsd:sequence> > <xsd:element ref="d"/> > <xsd:element ref="e"/> > </xsd:sequence> > <xsd:sequence> > <xsd:element ref="d"/> > <xsd:element ref="f"/> > </xsd:sequence> > </xsd:choice> > </xsd:complexType> > </xsd:element> > <xsd:element name="a"/> > <xsd:element name="b"/> > <xsd:element name="c"/> > <xsd:element name="d"/> > <xsd:element name="e"/> > <xsd:element name="f"/> > </xsd:schema> > > Many Thanks, > Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304568.html Hi Andy, Does something like the following work? ... <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence minOccurs="0"> <xsd:element ref="d"/> <xsd:choice> <xsd:sequence> <xsd:element ref="e"/> <xsd:element ref="f" minOccurs="0"/> </xsd:sequence> <xsd:element ref="f"/> </xsd:choice> </xsd:sequence> ... HTH, Pete. -- ============================================= Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using XML C++ data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ============================================= ----- Original Message ----- From: "Neill, Andrew" <andy.neill@siemens.com> To: <xmlschema-dev@w3.org> Sent: Wednesday, October 07, 2009 5:10 PM Subject: xsd ambigious Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304569.html Can anyone help with this XSD please? It doesnt seem to work? Essentially i want to ensure that if "E" or "F" are populated then "D" is populated before them. The rest of the elements can appear in any order and any amount of times. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="element"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <xsd:element ref="a" minOccurs="0"/> <xsd:element ref="b" minOccurs="0"/> <xsd:element ref="c" minOccurs="0"/> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="e"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="d"/> <xsd:element ref="f"/> </xsd:sequence> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="a"/> <xsd:element name="b"/> <xsd:element name="c"/> <xsd:element name="d"/> <xsd:element name="e"/> <xsd:element name="f"/> </xsd:schema> Many Thanks, Andy]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304562.html On 6 Oct 2009, at 14:45 , Kevin Braun wrote: > Hello, > > > Can anyone explain the following comment from the "changes since" in > XSD 1.1? > > "When an |xsi:type| attribute appears on an element, and has a QName > as its value, but the QName does not resolve to a known type > definition, processors are now required to "fall back" to lax > validation, using the declared {type <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition > > > definition} <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition> > of the ·governing element declaration· <http://www.w3.org/TR/xmlschema11-1/#key-governing-ed > > as the ·governing type definition· <http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem > >." > > > > First, I believe that lax validation is by definition against > xs:anyType, so I'm not sure what it means to do lax validation using > some other type. You're right; the description should not use the term 'lax validation'. The new rule is an attempt to define more useful fallback behavior than fallback to lax validation. > > Second, such a case as is being described violates rule 4 of Element > Locally Valid (Element) (§3.3.4.3) <http://www.w3.org/TR/xmlschema11-1/#cvc-elt > > (the instance-specified type definition would be absent), Correct. So the element is not marked valid. > and I don't see where there is any exception made to it. There is > some verbiage (in §3.3.4.3) about what happens to the governing type > declaration in this case, but I don't think this verbiage is giving > an exception to rule 4 (I assume it is summarizing the application > of the definition of "governing type declaration"). Clause 5 of the validation rule says that the element is to be validated against its governing type definition. This doesn't constitute an exception to clause 4. Validating the element against the declared type, rather than xsd:anyType, can be helpful when the downstream processor wishes to recover from the missing component and when the declared type has some local element declarations which would not be found by validating the element against xsd:anyType. > Schema-Validity Assessment (Element) (§3.3.4.6) <http://www.w3.org/TR/xmlschema11-1/#cvc-assess-elt > > does give a requirement for lax assessment according to > xs:anyType, but I don't think it applies here because the situation > described doesn't prevent assessment - it just has "invalid" as the > outcome. Besides that, the type to use for the lax assessment > doesn't agree with the statement I quoted. > > So, in short, I don't know what to make of the above statement. I hope the comments above help clarify things. > Can anyone point me to where the "fall back" requirement can be > found? I'm not sure whether you mean "what user requirement does this serve?" (answer: better behavior in the case of missing components), or "why does the change list say that the processor falls back to the declared type?" (answer: because clause 5 of Element Locally Valid (Element) says to validate the element against its governing type definition, and the definition of governing type definition says that if the instance-specified type does not successfully override the selected or declared type [which will be the case if the value of the xsi:type attribute fails to resolve], then the element's declared type will be the governing type). HTH -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304430.html Hello, Can anyone explain the following comment from the "changes since" in XSD 1.1? "When an |xsi:type| attribute appears on an element, and has a QName as its value, but the QName does not resolve to a known type definition, processors are now required to "fall back" to lax validation, using the declared {type <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition> definition} <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition> of the ·governing element declaration· <http://www.w3.org/TR/xmlschema11-1/#key-governing-ed> as the ·governing type definition· <http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem>." First, I believe that lax validation is by definition against xs:anyType, so I'm not sure what it means to do lax validation using some other type. Second, such a case as is being described violates rule 4 of Element Locally Valid (Element) (§3.3.4.3) <http://www.w3.org/TR/xmlschema11-1/#cvc-elt> (the instance-specified type definition would be absent), and I don't see where there is any exception made to it. There is some verbiage (in §3.3.4.3) about what happens to the governing type declaration in this case, but I don't think this verbiage is giving an exception to rule 4 (I assume it is summarizing the application of the definition of "governing type declaration"). Schema-Validity Assessment (Element) (§3.3.4.6) <http://www.w3.org/TR/xmlschema11-1/#cvc-assess-elt> does give a requirement for lax assessment according to xs:anyType, but I don't think it applies here because the situation described doesn't prevent assessment - it just has "invalid" as the outcome. Besides that, the type to use for the lax assessment doesn't agree with the statement I quoted. So, in short, I don't know what to make of the above statement. Can anyone point me to where the "fall back" requirement can be found? Thanks, -- Kevin Braun Objective Systems, Inc. http://www.obj-sys.com]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304424.html Michael - you've asked for feedback about whether redefine should be deprecated. I believe it should. I believe that the primary purpose for which schemas are written is an attempt to facilitate automated data exchange between computer systems. Features which in practice provide an "impedance" to the smooth automation of data exchange are bad. This email thread provides a classic illustration of a feature which has resulted in troubled and problematic implementation. With regard to this discussion creeping onto other features such as complex type derivation by restriction, I don't think it is particularly helpful of you to suggest that people stick to programming languages which support the same data structure concepts as XML Schema! Picking up your own point from another email on this thread, schema is widely used as a data interchange format even though it originated in document markup. Data interchange involves sending and receiving systems, and to my mind an interchange definition which aims at facilitating smooth automation should dovetail reasonably easily with technologies commonly used - the words "cart", "horse", "tail" and "dog" spring to mind! I think schema has often been criticised as over-complicated and over-sophisticated. Maybe definition of some subset of schema facilities for common data interchange would help in this whole area, although obviously attempting such an exercise would not be an easy one. From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael Kay Sent: 01 October 2009 23:53 To: 'XMLSchema at XML4Pharma'; xmlschema-dev@w3.org Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? Just for the record (though it only really confirms the point that there are differing interpretations), I implemented the XSD 1.0 specification without the benefit of knowing anything about the intent of the WG beyond what was written in the spec, and I came to the conclusion that there was only one way of interpreting the rule about xsd:redefine being "pervasive". But then I also came to the conclusion that other parts of the schema composition rules had to be treated as loose statements of intent which didn't cover all contingencies. I would certainly advise against using xs:redefine in an industry schema specification. Its only possible justification in my view is to define a variant of a schema produced by a third party. And for that use case, I think it only works unambiguously if that schema uses a single target namespace throughout. Michael Kay Saxonica ________________________________ From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of XMLSchema at XML4Pharma Sent: 29 September 2009 12:24 To: xmlschema-dev@w3.org Subject: Escalation mechanism for different interpretation of W3C XML-Schema specification ? 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 Disclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments.]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304307.html Michael Kay writes: > When XML was first conceived, I think most people expected it to be used > primarily for documents (I had heard people talking about using SGML for > data in the 1980s, and I thought they were nuts). It's > interesting to review > why XML proved successful as a data interchange format even > though it wasn't > primarily designed for that role. Well, as I've said many times, I believe it's in large part because the use cases aren't always separate. Many of the most interesting documents mix in real data. An insurance policy template, for example, probably has some sort of smart hook to pull in the name of the user and the exact amount of the policy, very possibly sourced from a relational database. So, I think that's what gets you into the business of having robust data typing, etc. Then the question is, do you for uniformity keep using XML in the degenerate case where it really is pure data, or drop back to something simpler. BTW: one of the reasons I'm attuned to this is that Lotus Notes (which I used early when I worked at Lotus, but did not help design) built a business on creating and managing just such mixed document/data constructions, well before XML (but not SGML) became popular. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Michael Kay" <mike@saxonica.com> 10/03/2009 12:11 PM To: <noah_mendelsohn@us.ibm.com>, "'XML4Pharma'" <info@XML4Pharma.com> cc: "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>, "'Dennis Sosnoski'" <dms@sosnoski.com>, <xmlschema-dev@w3.org> Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > > So JSON may be a good alternative. > > I would never discourage you from looking for the best > language to meet your needs, and JSON is in many respects > simpler than XML. That said, keep in mind that JSON is > fundamentally aimed at what we informally call "data", I.e. > roughly the sorts of things that fit well into a Java, C, or > (of course) Javascript structure. When XML was first conceived, I think most people expected it to be used primarily for documents (I had heard people talking about using SGML for data in the 1980s, and I thought they were nuts). It's interesting to review why XML proved successful as a data interchange format even though it wasn't primarily designed for that role. * XML was very cheap to implement (cost of writing tools, cost of buying tools, cost of putting them to good use) * For some reason I have never understood, XML had no serious competition, and had universal endorsement from all influential players * XML filled a gap. Many people with data interchange problems had devised custom solutions at layer 6 of the stack, and they all involved a lot of effort to maintain, and no generic tooling was available. These solutions often failed to solve the character sets problem. Other people had adopted ASN.1, which was unaffordable by the masses ($100K for a parser). * XML was genuinely open and platform-independent: people trusted the independence of the authority responsible for the specification, and there was neither an explicit nor a covert bias to particular operating systems, vendors, or programming languages. And there were no doubts about what was or was not valid XML (as there are with JSON). * For the first time in the history of computing, people were finding that documents and data could no longer be kept separate. People were building web sites in which information, entertainment, and transactions needed to be seamlessly mixed. * The high level of redundancy in XML, which we love to complain about, proved a winner in making it easy to formats to evolve gracefully. If JSON had been around before XML, the first three arguments would have been far less compelling. But the others would still have been strong. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304196.html > > So JSON may be a good alternative. > > I would never discourage you from looking for the best > language to meet your needs, and JSON is in many respects > simpler than XML. That said, keep in mind that JSON is > fundamentally aimed at what we informally call "data", I.e. > roughly the sorts of things that fit well into a Java, C, or > (of course) Javascript structure. When XML was first conceived, I think most people expected it to be used primarily for documents (I had heard people talking about using SGML for data in the 1980s, and I thought they were nuts). It's interesting to review why XML proved successful as a data interchange format even though it wasn't primarily designed for that role. * XML was very cheap to implement (cost of writing tools, cost of buying tools, cost of putting them to good use) * For some reason I have never understood, XML had no serious competition, and had universal endorsement from all influential players * XML filled a gap. Many people with data interchange problems had devised custom solutions at layer 6 of the stack, and they all involved a lot of effort to maintain, and no generic tooling was available. These solutions often failed to solve the character sets problem. Other people had adopted ASN.1, which was unaffordable by the masses ($100K for a parser). * XML was genuinely open and platform-independent: people trusted the independence of the authority responsible for the specification, and there was neither an explicit nor a covert bias to particular operating systems, vendors, or programming languages. And there were no doubts about what was or was not valid XML (as there are with JSON). * For the first time in the history of computing, people were finding that documents and data could no longer be kept separate. People were building web sites in which information, entertainment, and transactions needed to be seamlessly mixed. * The high level of redundancy in XML, which we love to complain about, proved a winner in making it easy to formats to evolve gracefully. If JSON had been around before XML, the first three arguments would have been far less compelling. But the others would still have been strong. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304195.html Jozef Aerts writes: > So JSON may be a good alternative. I would never discourage you from looking for the best language to meet your needs, and JSON is in many respects simpler than XML. That said, keep in mind that JSON is fundamentally aimed at what we informally call "data", I.e. roughly the sorts of things that fit well into a Java, C, or (of course) Javascript structure. JSON is typically not good at dealing with structured documents, in which multiple paragraphs must be kept in order, and mixed with other structures such as address fields, approval markings, signatures, or text formatting information. It's not that you can do that with JSON, but in complex cases you wind up doing a lot of work in nonstandard ways. So my guideline would be: if you're really dealing with fairly pure "data", take your pick according to the skills of your programmers, the tooling you want to use, and especially the expectations of those with whom you will be sharing the data. If you have lots of document-style information to deal with (and there are sort of vague estimates that the vast majority of information that computers deal with is more like that these day), then I'd think twice before using something like JSON. Instead, I'd go with a custom XML vocabulary, or if you prefer, an Open Document Format file. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "XML4Pharma" <info@XML4Pharma.com> 10/03/2009 06:13 AM Please respond to "XML4Pharma" To: "Michael Kay" <mike@saxonica.com>, "'Dennis Sosnoski'" <dms@sosnoski.com>, <noah_mendelsohn@us.ibm.com> cc: "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>, <xmlschema-dev@w3.org> Subject: Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? In our extension schemas, we only use "redefine" to ADD extra attributes and elements (in a separate namespace), not to change or remove any existing ones. One of my positive surprises with the way we implemented it, is that a XML data binding like XMLBeans had no problem at all working with it: it was very easy to derive all classes from our schemas including the "redefine". Dennis suggested to have a look at JSON, which I did. This might be a very good idea for a format for submitting information/data to the FDA. The problem at the FDA is that there is almost noone there with a basic understanding of XML, and those who have left the FDA to become a well-paid consultant. Some departments at the FDA have the greatest difficulty to validate even very simple XML documents. The FDA is currently planning to switch to HL7-v3-XML messages for electronic submissions of data to the agency. As HL7-v3-XML is highly complex (and even not good XML i.m.o.) I think this will lead to disaster. So JSON may be a good alternative. I had a quick look, but JSON does not have some data types like date, time and dateTime. Would be nice if they had ... Best, Jozef Aerts XML4Pharma ----- Original Message ----- From: "Michael Kay" <mike@saxonica.com> To: "'Dennis Sosnoski'" <dms@sosnoski.com>; <noah_mendelsohn@us.ibm.com> Cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>; "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>; <xmlschema-dev@w3.org> Sent: Saturday, October 03, 2009 12:43 AM Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > > While I think many of your criticisms of xs:redefine and complex type > restriction and indeed xs:override are valid, I personally don't accept > the > premise that XSD should be constrained or influenced by the data typing > paradigms of conventional programming languages. XML and XSD are first and > formost intended for designing hierarchic document structures (a > discipline > with a far longer tradition than programming), and the fact that > conventional programming languages don't support such structures very well > means in my view that it's best to switch to languages that do. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > >> -----Original Message----- >> From: xmlschema-dev-request@w3.org >> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dennis Sosnoski >> Sent: 02 October 2009 23:10 >> To: noah_mendelsohn@us.ibm.com >> Cc: XMLSchema at XML4Pharma; C. M. Sperberg-McQueen; >> xmlschema-dev@w3.org >> Subject: Re: Escalation mechanism for different >> interpretation of W3C XML-Schema specification ? >> >> Hi Noah, >> >> IMHO both xs:redefine and xs:complexType restriction should >> be eliminated. With respect to the increasingly important >> area of XML data binding for programming languages, redefine >> and complexType restriction are generally ignored for the >> simple reason that they have no equivalent in terms of data >> models. The object oriented programming equivalent of >> complexType restriction would be to define a subclass by >> eliminating information from the parent class, which is a >> bizarre concept in programming terms - if you want a limited >> representation which is not supported by the current data >> model you either refactor the data model to support the >> particular subset you want or use a representation which has >> more features than you need, with semantic constraints on the usage. >> There are times when this limitation of object oriented >> programming is inconvenient, but I suspect the vast majority >> of developers would agree that the benefits in terms of clean >> data models more than outweigh the inconvenience. >> >> Beyond this, the very nature of complexType restriction, >> which requires repeating all portions of the original model >> which are being retained, creates brittle definitions. >> >> redefine is an even stranger operation, effectively >> performing surgery on an existing definition to deform it in >> ways never intended by the original designers. One >> consequence is that anyone looking at an instance of an XML >> structure defined by a schema needs to be aware of other >> schemas which may have modified the original schema definition. >> Requiring knowledge of the entire set of schemas involved in >> a document in order to understand one particular component of >> the document is contrary to good design principles. >> >> It's hard for me to see how xs:override represents any kind >> of improvement on redefine, so asking for feedback on >> deprecating redefine while adding override into the mix seems >> deliberately futile. From my point of view override suffers >> from the same design failures as redefine, and should also be >> eliminated. >> >> I realize that many uses of W3C schema are not concerned with >> data binding, but I'd suggest that the difficulty of modeling >> these constructs in terms of modern programming language >> structures shows that they could be eliminated without >> significantly harming the usefulness of schema. >> >> - Dennis >> >> Dennis M. Sosnoski >> XML and Web Services in Java >> Training and Consulting >> http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, >> WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 >> >> >> >> noah_mendelsohn@us.ibm.com wrote: >> > I strongly urge you to read Michael Sperberg-McQueen's note >> carefully. >> > While, as noted below, some of my preferences for resolving >> > ambiguities happen to be different from his, I believe that >> his email >> > very accurately and carefully summarizes the state of play on this >> > issue. Let me just quote and comment on a few sections of >> Michael's note: >> > >> > >> >> 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. >> >> >> > >> > Yes, that's what it says, and it's contradictory. >> > >> > >> >> 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. >> >> >> > >> > Yes, those are at least two of the widely held positions as to what >> > was "really" intended, and I don't think I'm aware of any others. >> > >> > >> >> 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. >> >> >> > >> > I happen to be one of the others who would prefer that the >> redefine be >> > pervasive, but the important point here is that either >> interpretation >> > is plausible, and we agree on that. >> > >> > >> >> 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. >> >> >> > >> > Here, I'd like to add one bit. While Michael is correct that the >> > working group has "agreed" on this, some of us joined in that >> > agreement with some hesitancy, because we believe that >> <redefine> has >> > seen widespread use, including in cases that do not trigger (or at >> > least do not as clearly >> > trigger) the ambiguities that are causing trouble here. >> So, in light >> > of those concerns, the working group also agreed to make the >> > deprecation of <redefine> a so-called Priority Feedback issue. >> > Quoting from the working draft [1]: >> > >> > ---- >> > Note: The redefinition feature described in the remainder of this >> > section is .deprecated. and may be removed from future versions of >> > this specification. Schema authors are encouraged to avoid >> its use in >> > cases where interoperability or compatibility with later >> versions of >> > this specification are important. >> > >> > Editorial Note: Priority Feedback Request >> > >> > The Working Group requests feedback from readers, schema authors, >> > implementors, and other users of this specification as to the >> > desirability of retaining, removing, deprecating, or not >> deprecating >> > the use of <redefine>. Since the <override> facility >> provides similar >> > functionality but does not require a restriction or >> extension relation >> > between the new and the old definitions of redefined >> components, the >> > Working Group is particularly interested in learning >> whether users of >> > this specification find that requirement useful or not. >> > ---- >> > >> > So, if any readers of this thread have opinions on the plan to >> > deprecate, the Schema Working group would welcome hearing >> about them. >> > I think it's worth noting that this thread has already made clear >> > that: 1) this is a known area of complexity and the working >> group has >> > already tried and so far failed to find an easy resolution >> acceptable >> > to all; 2) there are incompatibilities in widely deployed >> > implementations, so any clear resolution is quite likely to make >> > someone with an investment in code very unhappy. That's >> not to say I >> > wouldn't like it cleaned up; indeed, I'm among those who put many >> > months into trying a few years ago (as did Michael). I'm >> just pointing >> > out that our choices may be to deprecate or undeprecate, but going >> > further to remove the ambiguity is likely to be a >> significant effort >> > that will introduce incompatibilities for at least >> somebody. Maybe or >> > maybe not we could find a way to warn people off from the most >> > troublesome cases, but I know that Michael and perhaps others will >> > correctly point out that the whole conceptual framework for this >> > "composition" function is sufficiently shaky in the current drafts >> > that any fix short of a complete rewrite is likely to leave >> things in a messy state. >> > >> > Noah >> > >> > [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema >> > >> > -------------------------------------- >> > Noah Mendelsohn >> > IBM Corporation >> > One Rogers Street >> > Cambridge, MA 02142 >> > 1-617-693-4036 >> > -------------------------------------- >> > >> > >> > >> > >> > >> > >> > >> > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304192.html In our extension schemas, we only use "redefine" to ADD extra attributes and elements (in a separate namespace), not to change or remove any existing ones. One of my positive surprises with the way we implemented it, is that a XML data binding like XMLBeans had no problem at all working with it: it was very easy to derive all classes from our schemas including the "redefine". Dennis suggested to have a look at JSON, which I did. This might be a very good idea for a format for submitting information/data to the FDA. The problem at the FDA is that there is almost noone there with a basic understanding of XML, and those who have left the FDA to become a well-paid consultant. Some departments at the FDA have the greatest difficulty to validate even very simple XML documents. The FDA is currently planning to switch to HL7-v3-XML messages for electronic submissions of data to the agency. As HL7-v3-XML is highly complex (and even not good XML i.m.o.) I think this will lead to disaster. So JSON may be a good alternative. I had a quick look, but JSON does not have some data types like date, time and dateTime. Would be nice if they had ... Best, Jozef Aerts XML4Pharma ----- Original Message ----- From: "Michael Kay" <mike@saxonica.com> To: "'Dennis Sosnoski'" <dms@sosnoski.com>; <noah_mendelsohn@us.ibm.com> Cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>; "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>; <xmlschema-dev@w3.org> Sent: Saturday, October 03, 2009 12:43 AM Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? > > While I think many of your criticisms of xs:redefine and complex type > restriction and indeed xs:override are valid, I personally don't accept > the > premise that XSD should be constrained or influenced by the data typing > paradigms of conventional programming languages. XML and XSD are first and > formost intended for designing hierarchic document structures (a > discipline > with a far longer tradition than programming), and the fact that > conventional programming languages don't support such structures very well > means in my view that it's best to switch to languages that do. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > >> -----Original Message----- >> From: xmlschema-dev-request@w3.org >> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dennis Sosnoski >> Sent: 02 October 2009 23:10 >> To: noah_mendelsohn@us.ibm.com >> Cc: XMLSchema at XML4Pharma; C. M. Sperberg-McQueen; >> xmlschema-dev@w3.org >> Subject: Re: Escalation mechanism for different >> interpretation of W3C XML-Schema specification ? >> >> Hi Noah, >> >> IMHO both xs:redefine and xs:complexType restriction should >> be eliminated. With respect to the increasingly important >> area of XML data binding for programming languages, redefine >> and complexType restriction are generally ignored for the >> simple reason that they have no equivalent in terms of data >> models. The object oriented programming equivalent of >> complexType restriction would be to define a subclass by >> eliminating information from the parent class, which is a >> bizarre concept in programming terms - if you want a limited >> representation which is not supported by the current data >> model you either refactor the data model to support the >> particular subset you want or use a representation which has >> more features than you need, with semantic constraints on the usage. >> There are times when this limitation of object oriented >> programming is inconvenient, but I suspect the vast majority >> of developers would agree that the benefits in terms of clean >> data models more than outweigh the inconvenience. >> >> Beyond this, the very nature of complexType restriction, >> which requires repeating all portions of the original model >> which are being retained, creates brittle definitions. >> >> redefine is an even stranger operation, effectively >> performing surgery on an existing definition to deform it in >> ways never intended by the original designers. One >> consequence is that anyone looking at an instance of an XML >> structure defined by a schema needs to be aware of other >> schemas which may have modified the original schema definition. >> Requiring knowledge of the entire set of schemas involved in >> a document in order to understand one particular component of >> the document is contrary to good design principles. >> >> It's hard for me to see how xs:override represents any kind >> of improvement on redefine, so asking for feedback on >> deprecating redefine while adding override into the mix seems >> deliberately futile. From my point of view override suffers >> from the same design failures as redefine, and should also be >> eliminated. >> >> I realize that many uses of W3C schema are not concerned with >> data binding, but I'd suggest that the difficulty of modeling >> these constructs in terms of modern programming language >> structures shows that they could be eliminated without >> significantly harming the usefulness of schema. >> >> - Dennis >> >> Dennis M. Sosnoski >> XML and Web Services in Java >> Training and Consulting >> http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, >> WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 >> >> >> >> noah_mendelsohn@us.ibm.com wrote: >> > I strongly urge you to read Michael Sperberg-McQueen's note >> carefully. >> > While, as noted below, some of my preferences for resolving >> > ambiguities happen to be different from his, I believe that >> his email >> > very accurately and carefully summarizes the state of play on this >> > issue. Let me just quote and comment on a few sections of >> Michael's note: >> > >> > >> >> 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. >> >> >> > >> > Yes, that's what it says, and it's contradictory. >> > >> > >> >> 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. >> >> >> > >> > Yes, those are at least two of the widely held positions as to what >> > was "really" intended, and I don't think I'm aware of any others. >> > >> > >> >> 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. >> >> >> > >> > I happen to be one of the others who would prefer that the >> redefine be >> > pervasive, but the important point here is that either >> interpretation >> > is plausible, and we agree on that. >> > >> > >> >> 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. >> >> >> > >> > Here, I'd like to add one bit. While Michael is correct that the >> > working group has "agreed" on this, some of us joined in that >> > agreement with some hesitancy, because we believe that >> <redefine> has >> > seen widespread use, including in cases that do not trigger (or at >> > least do not as clearly >> > trigger) the ambiguities that are causing trouble here. >> So, in light >> > of those concerns, the working group also agreed to make the >> > deprecation of <redefine> a so-called Priority Feedback issue. >> > Quoting from the working draft [1]: >> > >> > ---- >> > Note: The redefinition feature described in the remainder of this >> > section is .deprecated. and may be removed from future versions of >> > this specification. Schema authors are encouraged to avoid >> its use in >> > cases where interoperability or compatibility with later >> versions of >> > this specification are important. >> > >> > Editorial Note: Priority Feedback Request >> > >> > The Working Group requests feedback from readers, schema authors, >> > implementors, and other users of this specification as to the >> > desirability of retaining, removing, deprecating, or not >> deprecating >> > the use of <redefine>. Since the <override> facility >> provides similar >> > functionality but does not require a restriction or >> extension relation >> > between the new and the old definitions of redefined >> components, the >> > Working Group is particularly interested in learning >> whether users of >> > this specification find that requirement useful or not. >> > ---- >> > >> > So, if any readers of this thread have opinions on the plan to >> > deprecate, the Schema Working group would welcome hearing >> about them. >> > I think it's worth noting that this thread has already made clear >> > that: 1) this is a known area of complexity and the working >> group has >> > already tried and so far failed to find an easy resolution >> acceptable >> > to all; 2) there are incompatibilities in widely deployed >> > implementations, so any clear resolution is quite likely to make >> > someone with an investment in code very unhappy. That's >> not to say I >> > wouldn't like it cleaned up; indeed, I'm among those who put many >> > months into trying a few years ago (as did Michael). I'm >> just pointing >> > out that our choices may be to deprecate or undeprecate, but going >> > further to remove the ambiguity is likely to be a >> significant effort >> > that will introduce incompatibilities for at least >> somebody. Maybe or >> > maybe not we could find a way to warn people off from the most >> > troublesome cases, but I know that Michael and perhaps others will >> > correctly point out that the whole conceptual framework for this >> > "composition" function is sufficiently shaky in the current drafts >> > that any fix short of a complete rewrite is likely to leave >> things in a messy state. >> > >> > Noah >> > >> > [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema >> > >> > -------------------------------------- >> > Noah Mendelsohn >> > IBM Corporation >> > One Rogers Street >> > Cambridge, MA 02142 >> > 1-617-693-4036 >> > -------------------------------------- >> > >> > >> > >> > >> > >> > >> > >> > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304180.html While I think many of your criticisms of xs:redefine and complex type restriction and indeed xs:override are valid, I personally don't accept the premise that XSD should be constrained or influenced by the data typing paradigms of conventional programming languages. XML and XSD are first and formost intended for designing hierarchic document structures (a discipline with a far longer tradition than programming), and the fact that conventional programming languages don't support such structures very well means in my view that it's best to switch to languages that do. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dennis Sosnoski > Sent: 02 October 2009 23:10 > To: noah_mendelsohn@us.ibm.com > Cc: XMLSchema at XML4Pharma; C. M. Sperberg-McQueen; > xmlschema-dev@w3.org > Subject: Re: Escalation mechanism for different > interpretation of W3C XML-Schema specification ? > > Hi Noah, > > IMHO both xs:redefine and xs:complexType restriction should > be eliminated. With respect to the increasingly important > area of XML data binding for programming languages, redefine > and complexType restriction are generally ignored for the > simple reason that they have no equivalent in terms of data > models. The object oriented programming equivalent of > complexType restriction would be to define a subclass by > eliminating information from the parent class, which is a > bizarre concept in programming terms - if you want a limited > representation which is not supported by the current data > model you either refactor the data model to support the > particular subset you want or use a representation which has > more features than you need, with semantic constraints on the usage. > There are times when this limitation of object oriented > programming is inconvenient, but I suspect the vast majority > of developers would agree that the benefits in terms of clean > data models more than outweigh the inconvenience. > > Beyond this, the very nature of complexType restriction, > which requires repeating all portions of the original model > which are being retained, creates brittle definitions. > > redefine is an even stranger operation, effectively > performing surgery on an existing definition to deform it in > ways never intended by the original designers. One > consequence is that anyone looking at an instance of an XML > structure defined by a schema needs to be aware of other > schemas which may have modified the original schema definition. > Requiring knowledge of the entire set of schemas involved in > a document in order to understand one particular component of > the document is contrary to good design principles. > > It's hard for me to see how xs:override represents any kind > of improvement on redefine, so asking for feedback on > deprecating redefine while adding override into the mix seems > deliberately futile. From my point of view override suffers > from the same design failures as redefine, and should also be > eliminated. > > I realize that many uses of W3C schema are not concerned with > data binding, but I'd suggest that the difficulty of modeling > these constructs in terms of modern programming language > structures shows that they could be eliminated without > significantly harming the usefulness of schema. > > - Dennis > > Dennis M. Sosnoski > XML and Web Services in Java > Training and Consulting > http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, > WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 > > > > noah_mendelsohn@us.ibm.com wrote: > > I strongly urge you to read Michael Sperberg-McQueen's note > carefully. > > While, as noted below, some of my preferences for resolving > > ambiguities happen to be different from his, I believe that > his email > > very accurately and carefully summarizes the state of play on this > > issue. Let me just quote and comment on a few sections of > Michael's note: > > > > > >> 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. > >> > > > > Yes, that's what it says, and it's contradictory. > > > > > >> 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. > >> > > > > Yes, those are at least two of the widely held positions as to what > > was "really" intended, and I don't think I'm aware of any others. > > > > > >> 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. > >> > > > > I happen to be one of the others who would prefer that the > redefine be > > pervasive, but the important point here is that either > interpretation > > is plausible, and we agree on that. > > > > > >> 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. > >> > > > > Here, I'd like to add one bit. While Michael is correct that the > > working group has "agreed" on this, some of us joined in that > > agreement with some hesitancy, because we believe that > <redefine> has > > seen widespread use, including in cases that do not trigger (or at > > least do not as clearly > > trigger) the ambiguities that are causing trouble here. > So, in light > > of those concerns, the working group also agreed to make the > > deprecation of <redefine> a so-called Priority Feedback issue. > > Quoting from the working draft [1]: > > > > ---- > > Note: The redefinition feature described in the remainder of this > > section is .deprecated. and may be removed from future versions of > > this specification. Schema authors are encouraged to avoid > its use in > > cases where interoperability or compatibility with later > versions of > > this specification are important. > > > > Editorial Note: Priority Feedback Request > > > > The Working Group requests feedback from readers, schema authors, > > implementors, and other users of this specification as to the > > desirability of retaining, removing, deprecating, or not > deprecating > > the use of <redefine>. Since the <override> facility > provides similar > > functionality but does not require a restriction or > extension relation > > between the new and the old definitions of redefined > components, the > > Working Group is particularly interested in learning > whether users of > > this specification find that requirement useful or not. > > ---- > > > > So, if any readers of this thread have opinions on the plan to > > deprecate, the Schema Working group would welcome hearing > about them. > > I think it's worth noting that this thread has already made clear > > that: 1) this is a known area of complexity and the working > group has > > already tried and so far failed to find an easy resolution > acceptable > > to all; 2) there are incompatibilities in widely deployed > > implementations, so any clear resolution is quite likely to make > > someone with an investment in code very unhappy. That's > not to say I > > wouldn't like it cleaned up; indeed, I'm among those who put many > > months into trying a few years ago (as did Michael). I'm > just pointing > > out that our choices may be to deprecate or undeprecate, but going > > further to remove the ambiguity is likely to be a > significant effort > > that will introduce incompatibilities for at least > somebody. Maybe or > > maybe not we could find a way to warn people off from the most > > troublesome cases, but I know that Michael and perhaps others will > > correctly point out that the whole conceptual framework for this > > "composition" function is sufficiently shaky in the current drafts > > that any fix short of a complete rewrite is likely to leave > things in a messy state. > > > > Noah > > > > [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema > > > > -------------------------------------- > > Noah Mendelsohn > > IBM Corporation > > One Rogers Street > > Cambridge, MA 02142 > > 1-617-693-4036 > > -------------------------------------- > > > > > > > > > > > > > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304152.html Hi Noah, IMHO both xs:redefine and xs:complexType restriction should be eliminated. With respect to the increasingly important area of XML data binding for programming languages, redefine and complexType restriction are generally ignored for the simple reason that they have no equivalent in terms of data models. The object oriented programming equivalent of complexType restriction would be to define a subclass by eliminating information from the parent class, which is a bizarre concept in programming terms - if you want a limited representation which is not supported by the current data model you either refactor the data model to support the particular subset you want or use a representation which has more features than you need, with semantic constraints on the usage. There are times when this limitation of object oriented programming is inconvenient, but I suspect the vast majority of developers would agree that the benefits in terms of clean data models more than outweigh the inconvenience. Beyond this, the very nature of complexType restriction, which requires repeating all portions of the original model which are being retained, creates brittle definitions. redefine is an even stranger operation, effectively performing surgery on an existing definition to deform it in ways never intended by the original designers. One consequence is that anyone looking at an instance of an XML structure defined by a schema needs to be aware of other schemas which may have modified the original schema definition. Requiring knowledge of the entire set of schemas involved in a document in order to understand one particular component of the document is contrary to good design principles. It's hard for me to see how xs:override represents any kind of improvement on redefine, so asking for feedback on deprecating redefine while adding override into the mix seems deliberately futile. From my point of view override suffers from the same design failures as redefine, and should also be eliminated. I realize that many uses of W3C schema are not concerned with data binding, but I'd suggest that the difficulty of modeling these constructs in terms of modern programming language structures shows that they could be eliminated without significantly harming the usefulness of schema. - Dennis Dennis M. Sosnoski XML and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 noah_mendelsohn@us.ibm.com wrote: > I strongly urge you to read Michael Sperberg-McQueen's note carefully. > While, as noted below, some of my preferences for resolving ambiguities > happen to be different from his, I believe that his email very accurately > and carefully summarizes the state of play on this issue. Let me just > quote and comment on a few sections of Michael's note: > > >> 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. >> > > Yes, that's what it says, and it's contradictory. > > >> 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. >> > > Yes, those are at least two of the widely held positions as to what was > "really" intended, and I don't think I'm aware of any others. > > >> 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. >> > > I happen to be one of the others who would prefer that the redefine be > pervasive, but the important point here is that either interpretation is > plausible, and we agree on that. > > >> 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. >> > > Here, I'd like to add one bit. While Michael is correct that the working > group has "agreed" on this, some of us joined in that agreement with some > hesitancy, because we believe that <redefine> has seen widespread use, > including in cases that do not trigger (or at least do not as clearly > trigger) the ambiguities that are causing trouble here. So, in light of > those concerns, the working group also agreed to make the deprecation of > <redefine> a so-called Priority Feedback issue. Quoting from the working > draft [1]: > > ---- > Note: The redefinition feature described in the remainder of this section > is ·deprecated· and may be removed from future versions of this > specification. Schema authors are encouraged to avoid its use in cases > where interoperability or compatibility with later versions of this > specification are important. > > Editorial Note: Priority Feedback Request > > The Working Group requests feedback from readers, schema authors, > implementors, and other users of this specification as to the desirability > of retaining, removing, deprecating, or not deprecating the use of > <redefine>. Since the <override> facility provides similar functionality > but does not require a restriction or extension relation between the new > and the old definitions of redefined components, the Working Group is > particularly interested in learning whether users of this specification > find that requirement useful or not. > ---- > > So, if any readers of this thread have opinions on the plan to deprecate, > the Schema Working group would welcome hearing about them. I think it's > worth noting that this thread has already made clear that: 1) this is a > known area of complexity and the working group has already tried and so > far failed to find an easy resolution acceptable to all; 2) there are > incompatibilities in widely deployed implementations, so any clear > resolution is quite likely to make someone with an investment in code very > unhappy. That's not to say I wouldn't like it cleaned up; indeed, I'm > among those who put many months into trying a few years ago (as did > Michael). I'm just pointing out that our choices may be to deprecate or > undeprecate, but going further to remove the ambiguity is likely to be a > significant effort that will introduce incompatibilities for at least > somebody. Maybe or maybe not we could find a way to warn people off from > the most troublesome cases, but I know that Michael and perhaps others > will correctly point out that the whole conceptual framework for this > "composition" function is sufficiently shaky in the current drafts that > any fix short of a complete rewrite is likely to leave things in a messy > state. > > Noah > > [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > > >]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304151.html Hi, In 3.16.6.2 Derivation Valid (Restriction, Simple) (http://www.w3.org/TR/xmlschema11-1/#cos-st-restricts), step 3.1.2.3 says: "Each type definition in D.{member type definitions} <http://www.w3.org/TR/xmlschema11-1/#std-member_type_definitions> is validly ·derived· <http://www.w3.org/TR/xmlschema11-1/#key-derived> from the corresponding type definition in B.{member type definitions} <http://www.w3.org/TR/xmlschema11-1/#std-member_type_definitions>, as defined in Type Derivation OK (Simple) (§3.16.6.3) <http://www.w3.org/TR/xmlschema11-1/#cos-st-derived-ok>." What purpose does this requirement serve? Isn't it the case that D.{member type definitions} is identical to B.{member type definitions}, since this case applies when defining a restriction on a union? Am I missing something, or is this superfluous? Thanks, Kevin]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304134.html Thanks Michael, About the justification you are mentioning: that is exactly what our standard is about: allowing companies (but also the FDA) to add extra elements and attributes in a separate namespace. The whole discussion is a trigger for us to move to XML-Schema 1.1 earlier than we envisaged. Problem here is that, except for Saxon, there do seem not to be very much tools (editors, libraries, etc.) that allow validation of XML files against XML-Schema 1.1. Is there a list somewhere of tools that do so, or a list of vendors and when they intend to have Schema-1.1 validation ready ? I will make a separate mailing with some comments/remarks/suggestions about escalation of issues, certification mechanisms, etc.. Jozef Aerts XML4Pharma ----- Original Message ----- From: Michael Kay To: 'XMLSchema at XML4Pharma' ; xmlschema-dev@w3.org Sent: Friday, October 02, 2009 12:53 AM Subject: RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? Just for the record (though it only really confirms the point that there are differing interpretations), I implemented the XSD 1.0 specification without the benefit of knowing anything about the intent of the WG beyond what was written in the spec, and I came to the conclusion that there was only one way of interpreting the rule about xsd:redefine being "pervasive". But then I also came to the conclusion that other parts of the schema composition rules had to be treated as loose statements of intent which didn't cover all contingencies. I would certainly advise against using xs:redefine in an industry schema specification. Its only possible justification in my view is to define a variant of a schema produced by a third party. And for that use case, I think it only works unambiguously if that schema uses a single target namespace throughout. Michael Kay Saxonica ---------------------------------------------------------------------------- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of XMLSchema at XML4Pharma Sent: 29 September 2009 12:24 To: xmlschema-dev@w3.org Subject: Escalation mechanism for different interpretation of W3C XML-Schema specification ? 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]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304100.html Just for the record (though it only really confirms the point that there are differing interpretations), I implemented the XSD 1.0 specification without the benefit of knowing anything about the intent of the WG beyond what was written in the spec, and I came to the conclusion that there was only one way of interpreting the rule about xsd:redefine being "pervasive". But then I also came to the conclusion that other parts of the schema composition rules had to be treated as loose statements of intent which didn't cover all contingencies. I would certainly advise against using xs:redefine in an industry schema specification. Its only possible justification in my view is to define a variant of a schema produced by a third party. And for that use case, I think it only works unambiguously if that schema uses a single target namespace throughout. Michael Kay Saxonica _____ From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of XMLSchema at XML4Pharma Sent: 29 September 2009 12:24 To: xmlschema-dev@w3.org Subject: Escalation mechanism for different interpretation of W3C XML-Schema specification ? 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 <http://www.altova.com/forum/default.aspx?g=posts&m=1000005665> &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]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304081.html > I am strongly for depreciating redefine (as well as inheritance by > restriction, while we are at it ;-)). I wouldn't like to see that deprecated, but as a matter of good practice, once people adopt XSD 1.1 I shall probably be advising them always to do restriction of complex content models by means of assertions. Michael Kay Saxonica]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304080.html Just the sort of feedback we need, thank you! It's quite possible that my intuition on this is wrong. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- Boris Kolpackov <boris@codesynthesis.com> 10/01/2009 11:57 AM To: noah_mendelsohn@us.ibm.com cc: XMLSchema at XML4Pharma <XMLSchema@XML4Pharma.com>, "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, xmlschema-dev@w3.org Subject: Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? Hi, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> writes: > because we believe that <redefine> has seen widespread use, I have a completely opposite experience. That is, I have seen people trying to use redefine, quickly finding that no two processors handle it the same way, and giving up. We also have a fairly large XML Schema repository which includes hundreds of schemas for various public and proprietary real-world vocabularies. I just did a quick check and the repository contains over 2,000 schema files. Only one vocabulary uses redefine. > So, if any readers of this thread have opinions on the plan to deprecate, > the Schema Working group would welcome hearing about them. I am strongly for depreciating redefine (as well as inheritance by restriction, while we are at it ;-)). Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304053.html Hi, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> writes: > because we believe that <redefine> has seen widespread use, I have a completely opposite experience. That is, I have seen people trying to use redefine, quickly finding that no two processors handle it the same way, and giving up. We also have a fairly large XML Schema repository which includes hundreds of schemas for various public and proprietary real-world vocabularies. I just did a quick check and the repository contains over 2,000 schema files. Only one vocabulary uses redefine. > So, if any readers of this thread have opinions on the plan to deprecate, > the Schema Working group would welcome hearing about them. I am strongly for depreciating redefine (as well as inheritance by restriction, while we are at it ;-)). Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde]]> http://www.altova.com/list/xmlschema-dev/200910/msg1000304052.html Hi all, I'm looking at 3.4.2.3.3 Mapping Rules for Content Type Property of Complex Content. The branch under 6.1 is the only case that allows the type being defined to pick up the openContent of the base type. However, whenever 5.2 applies (the wildcard element is based on the schema's defaultOpenContent), 6.1 does not apply. So, if I have a defaultOpenContent, then in many cases of complex type extension, the new type will not inherit the openContent of its base type. Am I reading that right? Is that the intention? I would think that the openContent of the base type should take precedence over the default. If the default open content is more restrictive than the base open content, then one would be forced to put an acceptable explicit openContent into the derived type; otherwise, the rules in "Derivation Valid (extension)" will be violated. It looks like the behavior for restrictions is similar, except that in that case, 6.1 would have caused the derived type to have openContent of "absent", while 5.2 may again prevent this by supplying the default openContent. Regards, Kevin]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303968.html I strongly urge you to read Michael Sperberg-McQueen's note carefully. While, as noted below, some of my preferences for resolving ambiguities happen to be different from his, I believe that his email very accurately and carefully summarizes the state of play on this issue. Let me just quote and comment on a few sections of Michael's note: > 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. Yes, that's what it says, and it's contradictory. > 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. Yes, those are at least two of the widely held positions as to what was "really" intended, and I don't think I'm aware of any others. > 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. I happen to be one of the others who would prefer that the redefine be pervasive, but the important point here is that either interpretation is plausible, and we agree on that. > 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. Here, I'd like to add one bit. While Michael is correct that the working group has "agreed" on this, some of us joined in that agreement with some hesitancy, because we believe that <redefine> has seen widespread use, including in cases that do not trigger (or at least do not as clearly trigger) the ambiguities that are causing trouble here. So, in light of those concerns, the working group also agreed to make the deprecation of <redefine> a so-called Priority Feedback issue. Quoting from the working draft [1]: ---- Note: The redefinition feature described in the remainder of this section is ·deprecated· and may be removed from future versions of this specification. Schema authors are encouraged to avoid its use in cases where interoperability or compatibility with later versions of this specification are important. Editorial Note: Priority Feedback Request The Working Group requests feedback from readers, schema authors, implementors, and other users of this specification as to the desirability of retaining, removing, deprecating, or not deprecating the use of <redefine>. Since the <override> facility provides similar functionality but does not require a restriction or extension relation between the new and the old definitions of redefined components, the Working Group is particularly interested in learning whether users of this specification find that requirement useful or not. ---- So, if any readers of this thread have opinions on the plan to deprecate, the Schema Working group would welcome hearing about them. I think it's worth noting that this thread has already made clear that: 1) this is a known area of complexity and the working group has already tried and so far failed to find an easy resolution acceptable to all; 2) there are incompatibilities in widely deployed implementations, so any clear resolution is quite likely to make someone with an investment in code very unhappy. That's not to say I wouldn't like it cleaned up; indeed, I'm among those who put many months into trying a few years ago (as did Michael). I'm just pointing out that our choices may be to deprecate or undeprecate, but going further to remove the ambiguity is likely to be a significant effort that will introduce incompatibilities for at least somebody. Maybe or maybe not we could find a way to warn people off from the most troublesome cases, but I know that Michael and perhaps others will correctly point out that the whole conceptual framework for this "composition" function is sufficiently shaky in the current drafts that any fix short of a complete rewrite is likely to leave things in a messy state. Noah [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303898.html Hi, Some time ago we have a similar problem in a project with one schema per "concept" aproach project, we create almost 3500 schema-s. (GEL-XML ). The XML-Spy validator is so different (so good) to other parsers, so you have o create (readable) schema-s for all parsers implementations, even worse to all code generators (e.g. jaxb, .net, etc), in order to be usable-s in the real world. The solution was to ban redefines and to use hierarchical proxy-schema-s (libraries), so the parser read one time and only one time the imported library with an unique namepace and/per location. The other (administrative) solution was to define one unique parser-brand to validate the schema-s. Cheers, César On Tue, Sep 29, 2009 at 9:47 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > XMLSchema at XML4Pharma writes: > > > Our extension mechanism is based on the "import" and "redefine" > > elements of XML-Schema. > > > [see] http://www.altova.com/forum/default.aspx?g=posts&m=1000005665 > > > We now want to escalate the issue to the W3C itself, and would like > > to know what the mechanism is to do so. > > We can only try to clarify and persuade -- we have no authority to > compel anyone. > > I can only explain how/why XSV behaves as it does, and offer my > understand of the spec. > > The spec. allows (note, _not_ requires) implementations to ignore > attempts to import schema documents for namespaces for which a schema > document is already known: > > "Given that the schemaLocation [attribute] is only a hint, it is > open to applications to ignore all but the first <import> for a > given namespace, regardless of the ·actual value· of > schemaLocation, but such a strategy risks missing useful > information when new schemaLocations are offered." [1] > > XSV follows this strategy. In the case of the CDISC schemas, this > means the xs:import of ODM1-2-1.xsd is skipped, because a schema > document (namely define-1.0.0.xsd) is already known for the odm/v1.2 > namespace. > > In the case of the Altova example, this means the xs:import of > XSD2.xsd is skipped, because a schema document (namely XSD1.xsd) is > already known for the no-target-namespace case. > > In other words, in neither case is the behaviour of XSD to do with how > it resolves redefine/import conflicts. > > But note that any schema processor which _does_ follow all > schemaLocation hints, and therefore does import multiple documents for > the same target namespace, is perfectly conformant as well. > > So, what about redefine/import conflicts? > > The spec. contains no explicit guidance. Furthermore, it is impossible to > construct an example which would provoke such a conflict in XSV, > because it would require two imports of the same targetNamespace (the > reason for this is left as an exercise for the reader -- if I've > missed a way to bring this about, I owe the first person to point out > how a beer :-). > > We can however construct an example of conflicting redefine/include in > XSV, by making small modifications to the XSD3.xsd document given in > the Altova example: > > XSD3.xsd > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified" attributeFormDefault="unqualified" > targetNamespace="http://XSD3 <http://xsd3/>" xmlns:x="http://XSD3<http://xsd3/> > "> > <xs:include schemaLocation="XSD2.xsd"/> > <xs:include schemaLocation="XSD1.xsd"/> > <xs:element name="elt" type="x:CT"/> > </xs:schema> > > We're now chameleon including/redefining, and the result works with > XSV 3.1, regardless of the order of the two include statements. By > 'works', I mean > a) The schema is judged to be OK; > b) The instance is judged to be bad. > > I read the spec. as _requiring_ this behaviour, because it says > > "The modifications have a pervasive impact, that is, only the > redefined components are used, even when referenced from other > incorporated components, whether redefined themselves or not." [2] > > What this means is that no conflict occurs between the redefined and > non-redefined components, because the later are not part of the schema > used for validation. The same argument seems to me to apply to the > redefine/import case. > > I would be interested to know how other products behave with the > redefine/include conflict example given above. > > Summary: I believe the spec. intends the redefine semantics to 'trump' > the include and import semantics wrt which components are present in > cases of conflict, but I do not disagree that this is not so clear as > to be uncontestable. > > I also think it is unfortunate that all implementors cannot agree on a > single interpretation. If it is true, as alleged, that the situation > is that many implementations agree on the interpretation but one does > not, that's particularly unfortunate. > > ht > > [1] http://www.w3.org/TR/xmlschema-1/#src-import > [1] http://www.w3.org/TR/xmlschema-1/#modify-schema > - -- > Henry S. Thompson, School of Informatics, University of Edinburgh > Half-time member of W3C Team > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without it is forged > spam] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFKwh4EkjnJixAXWBoRAsVuAJ9PFjtJMUNAycnVwR3WlFIrJVCI3wCfVeQX > c0UQGS14hYnXrTq2lW2ADVE= > =m9RM > -----END PGP SIGNATURE----- > >]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303897.html 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 ****************************************************************]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303891.html -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 XMLSchema at XML4Pharma writes: > Our extension mechanism is based on the "import" and "redefine" > elements of XML-Schema. > [see] http://www.altova.com/forum/default.aspx?g=posts&m=1000005665 > We now want to escalate the issue to the W3C itself, and would like > to know what the mechanism is to do so. We can only try to clarify and persuade -- we have no authority to compel anyone. I can only explain how/why XSV behaves as it does, and offer my understand of the spec. The spec. allows (note, _not_ requires) implementations to ignore attempts to import schema documents for namespaces for which a schema document is already known: "Given that the schemaLocation [attribute] is only a hint, it is open to applications to ignore all but the first <import> for a given namespace, regardless of the ·actual value· of schemaLocation, but such a strategy risks missing useful information when new schemaLocations are offered." [1] XSV follows this strategy. In the case of the CDISC schemas, this means the xs:import of ODM1-2-1.xsd is skipped, because a schema document (namely define-1.0.0.xsd) is already known for the odm/v1.2 namespace. In the case of the Altova example, this means the xs:import of XSD2.xsd is skipped, because a schema document (namely XSD1.xsd) is already known for the no-target-namespace case. In other words, in neither case is the behaviour of XSD to do with how it resolves redefine/import conflicts. But note that any schema processor which _does_ follow all schemaLocation hints, and therefore does import multiple documents for the same target namespace, is perfectly conformant as well. So, what about redefine/import conflicts? The spec. contains no explicit guidance. Furthermore, it is impossible to construct an example which would provoke such a conflict in XSV, because it would require two imports of the same targetNamespace (the reason for this is left as an exercise for the reader -- if I've missed a way to bring this about, I owe the first person to point out how a beer :-). We can however construct an example of conflicting redefine/include in XSV, by making small modifications to the XSD3.xsd document given in the Altova example: XSD3.xsd <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="http://XSD3" xmlns:x="http://XSD3"> <xs:include schemaLocation="XSD2.xsd"/> <xs:include schemaLocation="XSD1.xsd"/> <xs:element name="elt" type="x:CT"/> </xs:schema> We're now chameleon including/redefining, and the result works with XSV 3.1, regardless of the order of the two include statements. By 'works', I mean a) The schema is judged to be OK; b) The instance is judged to be bad. I read the spec. as _requiring_ this behaviour, because it says "The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not." [2] What this means is that no conflict occurs between the redefined and non-redefined components, because the later are not part of the schema used for validation. The same argument seems to me to apply to the redefine/import case. I would be interested to know how other products behave with the redefine/include conflict example given above. Summary: I believe the spec. intends the redefine semantics to 'trump' the include and import semantics wrt which components are present in cases of conflict, but I do not disagree that this is not so clear as to be uncontestable. I also think it is unfortunate that all implementors cannot agree on a single interpretation. If it is true, as alleged, that the situation is that many implementations agree on the interpretation but one does not, that's particularly unfortunate. ht [1] http://www.w3.org/TR/xmlschema-1/#src-import [1] http://www.w3.org/TR/xmlschema-1/#modify-schema - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKwh4EkjnJixAXWBoRAsVuAJ9PFjtJMUNAycnVwR3WlFIrJVCI3wCfVeQX c0UQGS14hYnXrTq2lW2ADVE= =m9RM -----END PGP SIGNATURE-----]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303888.html 2009/9/29 XMLSchema at XML4Pharma <XMLSchema@xml4pharma.com>: > 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. This was talked about before: http://markmail.org/message/ccxa6gbyvn3773kx The advice you were given back then was "xs:redefine is pretty messy, and the best advice is to avoid it" so it seems a little odd to now take the stance you have... especially when you say most of your customers use Altova. I can understand your frustrations, but I'm not too sure what your want to achieve here - even if Altova agree you're right and a make a fix for their next release, it will still take a long time for that version to filter down to your existing customers, if at all. By the way, what does "escalating it to the W3C" mean? This reminds me of a project where the app worked fine on everything except IE 5.5 on windows NT, and that was what the majority of the users were on.... it would have been nice to escalate the issue to make the problem go away :) but sadly we had to code around it. Not very helpful I know, sorry, perhaps you could move straight to XSD 1.1? -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303884.html 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]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303879.html Ian, and everyone: I chewed over this whole tempest through a leisurely, solo lunch. And as I masticated, I considered the original directive given to DARPA deep in the bowels of the Pentagon around the time that I was born, from which all of this (and a great deal more) has resulted. And it all seems consistent to me. At the risk of sounding pedantic, I have to repeat that the overriding need which brought the Internet into being was for army posts to be able to continue to communicate with each other IN THE EVENT THAT HQ GOT KNOCKED OUT by nuclear blast or other means. It is that fact which makes it so "democratic" and so impossible for any authority to regulate or control. Sometimes we love that. Sometimes we don't. But that's the way it is. And I think it will stay that way. On this particular issue, I think that eventually all of us who are building and storing and editing and displaying geographic information metadata, will come to use approximately (but not exactly) the same conventions, methodologies, taxonomies, structures, etc., with the aid of published "standards" which will never be completely unique, precise, dogmatic and persistent, but will nevertheless, help. -JohnT SCISOFT wrote: > The more basic problem with URL's, URI's, and URN's is > that, as Michael S-M points out, a domain name isn't permanent, > > it can be abandoned and then picked up by a different party. > > While its highly unlikely that a particular set of schemas, a > "standard" > > be spoofed, (much more likely that the validator request > > would return a "404") its entirely possible. > > I’m sure this is just a small part of the significant discussions, but > it’s very irritating. > > That seems to epitomise the W3C’s quagmire created by such irrelevant > reductio ab absurbum arguments for a number of topic, which I believe > has been worsening during the last 12 years. In some circumstances, > pragmatism is necessary (even though XML 1.0 got some things very > wrong – eg, name collision - that was rectified: the namespaces > concept was introduced). > > Isn’t it a problem with the ‘improper’ association of URLs-URIs-URNs? > > The most important attribute of a namespace identifier is that it is > unique. Authors can guarantee the uniqueness of a URL by registering a > domain name with an Internet naming authority. Then it's the author's > responsibility to make sure that all strings used after the domain > name are unique. URNs work the same way. > > To guarantee the uniqueness of a URN, authors must again register > their namespace identifier with an Internet naming authority. The > author is then responsible for following a scheme for generating > unique namespace-specific strings. > > Organizations defining XML namespaces should develop a consistent > scheme for creating new namespace names. > > Maybe I’m simplifying or misunderstanding the strict definitions, but > here’s a proposition that diverges significantly from the above. > > Although it may be imperfect compared with a strictly-formulated > validating or registering authority, an interim system based on GUIDs > (urn:uuid) might have been widely implemented. > > At any time, the W3C itself (or a commercial organization such as > VeriSign) could have set up an interim system that equated a URN to a > unique and permanent GUID. In the same way that the DNS system > operates for URLs, this (interim) “GUID Authority” could have > maintained a precisely versioned schema set for each namespace GUID > without tying it to a URL locator. > > The 404 problem need not ever occur. > > The GUID-URI “DNS” would always maintain the simple lookup, and it > would be a very modest-sized database. A series of status / validity / > last changed flags could be supplement the system – so, redundant > GUID-URNs that never “went anywhere” could just linger without dying, > without detriment. > > Since there is a very large number of unique GUIDs, paradoxically I > think that versioning and authentication is not as difficult a problem > as with the URN, where choosing and usage of URNs is very dependent on > the constraints of human factors. > > Ian Thomas > > GeoSciSoft - Perth, Australia > > -----Original Message----- > From: John.Tucker [mailto:John.Tucker@noaa.gov] > Sent: Tuesday, 22 September 2009 11:00 PM > To: SCISOFT > Subject: Re: [metadata] versions and profiles of ISO 19139 > > You are correct about that ... > > One part of the discussions is around > > different versions or profiles of the same standard ... > > neither the W3C nor anyone else has ever set down a standard mechanism > > for doing this in a namespace ... > > in some situations, an update which "includes" the previous version > > and then merely provides additions and deletions seems most > appropriate, > > in some situations, putting different schema versions in the same > namespace > > seems most appropriate, > > in some situations, a whole new namespace seem better. > > But there is no "standard" way to do any of these things, > > so schema validating processors simply don't know how to handle > > changing versions. > > The more basic problem with URL's, URI's, and URN's is > > that, as Michael S-M points out, a domain name isn't permanent, > > it can be abandoned and then picked up by a different party. > > While its highly unlikely that a particular set of schemas, a > "standard" > > be spoofed, (much more likely that the validator request > > would return a "404") its entirely possible. > > -JohnT > > SCISOFT wrote: > > > John > > > I haven't followed these types of discussions, so I'd guess that > this > > > suggestion ha been thrashed to death: GUIDs. > > > What's the problem with a unique identifier rather than a registrant > > > authority ? > > > > > > IL Thomas > > > GeoSciSoft - Perth, Australia > > > > > > -----Original Message----- > > > From: John.Tucker [mailto:John.Tucker@noaa.gov] > > > Sent: Tuesday, 22 September 2009 10:31 PM > > > To: SCISOFT > > > Subject: Re: [metadata] versions and profiles of ISO 19139 > > > > > > The significance of this issue is > > > that we are all working towards the use of authoritative standards > for our > > > metadata. > > > However, so far, the very nature of the InterNet is that it eschews > > > authority. > > > > > > Up through now, there is no way to guarantee the integrity and > persistence > > > of > > > any resource. > > > > > > Here are the quotes that I selected > > > (with email addresses ... please be nice ...) > > > > > > At present, there is (unfortunately!) no service to guarantee the > uniqueness > > > and persistence of URN's, Universal resource names. "The fact that > there is > > > no general URN resolution service (besides reading the relevant > RFCs) is > > > highly iconvenient and pragmatically it is a killer." - Simon Cox > > > <simon.cox@jrc.ec.europa.eu> > > > > > > "The Namespace Recommendation: It is not a goal that it be directly > usable > > > for retrieval of a schema." -Henry Thompson <ht@inf.ed.ac.uk> > > > > > > "The only way to ensure safe processing [of different versions](i.e. > that > > > respects *all* of the processing strategies allowed for in the XML > schema > > > spec) is to be scrupulous about changing the namespace if the schema > > > changes." -Simon Cox > > > > > > "But as long as domain names are allowed to be used more than once > by > > > different owners, no system of unique identifiers built on the > domain name > > > system actually guarantees uniqueness of identifier." - C.M. > > > Sperberg-McQueen <cmsmcq@blackmesatech.com> > > > > > > -John Tucker > > > > > > SCISOFT wrote: > > > > > > > John > > > > Unfortunately afaik this list doesn't allow attachments (they get > filtered > > > > out?). > > > > I'd like to see the quotes. Perhaps you could paste them in-line > into an > > > > email to the list? > > > > > > > > IL Thomas > > > > GeoSciSoft - Perth, Australia > > > > > > > > -----Original Message----- > > > > From: metadata-bounces+geoscisoft=iinet.net.au@lists.geocomm.com > > > > > [mailto:metadata-bounces+geoscisoft=iinet.net.au@lists.geocomm.com] On > > > > Behalf Of John.Tucker > > > > Sent: Tuesday, 22 September 2009 3:36 AM > > > > To: metadata@lists.geocomm.com > > > > Subject: [metadata] versions and profiles of ISO 19139 > > > > > > > > The <xmlschema-dev@w3.org> mailing list > > > > is a venarable discussion group where some of the > > > > most luninary and faithful contributors to the XML family > > > > of standards still participate and contribute. > > > > During the past 4 weeks or so, people including > > > > Simon Cox, C.M. Sperberg-McQueen, and Henry Thompson > > > > discussed what rules there are and what rules there aren't, > > > > concerning versions and profiles. > > > > Since those of us aiming at ISO 19139 now anticipate > > > > some new versions and profiles, this subject is extremely > > > > relevant. > > > > Without pretending to have near as much insight as those > > > > people, I present a few of their quotes for our consideration, > > > > just in case there are people on this list who have not yet > > > > considered the implications. The full discussion should be in > their > > > > archives and is well-recommended. > > > > > > > > -John Tucker >]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000303418.html Henry, Long time no chat, hope all your pipes are clear and no ciphers! I am sitting here at home, on extended sick leave, and I feel like I am the only audience to a horror movie, the only one who happens to be privy to a host of disparate pieces of arcane information which, taken all together, show a number of protagonists walking blind into your typical disaster ... there are some large constituencies with some pretty basic assumptions which stand to fall apart without a standard on namespaces and schema versions. Here are the pieces that I know of: International Standards Organization standard 19115, geographic Information, Metadata, which has been in place for 5 years and garnered considerable respect and a few good tries at compliance. It is currently undergoing 5-year review with the reasonable expectation that there will be some changes. ISO 19115-2, an extension of the above for Remote Sensing applications. ISO 19139, an XML encoding of the 19115 standard. does not include 19115-2. Includes a set of W3C schema language schemas and some additional business rules. The ISO does provide and maintain a namespace with the schemas. A set of schemas written between 2 and 3 years ago by a gentleman working for US DOD defense mapping agency-or-whatever-they-were-called-at-the-time. the gentleman died suddenly. the schemas differ significantly from the 19139 schemas but this information is not generally known. The schemas are used by data creation and editing software owned, sold and maintained by CARIS, the dominant nautical chartmaking software company worldwide. many (1000+?) datasets now exist using these. A text document in the final stages of approval, known as "The North American Profile (NAP)" of 19115, which involves only a couple of simple but important restrictions of the existing 19139 schemas. At least one of my colleagues attempting to write a different set of schemas according to this document and to file them in a different namespace. A US Government inter-agency committee (FGDC) which has the power to mandate that all US govt agencies use these schemas is contemplating their own set on their own namespace. An on-going effort (at least 14 years by my reckoning ...)by a group known as TSMAD under the auspices of the International Hydrographic Organization to develop a standard for nautical data which may incorporate the 19115 standard or the 19139 schemas and will certainly label anything originating in North America as unacceptable, and may require the US nautical chartmaking authorities to employ it. Now I am quite confident in your ability to surmise some of the impending difficulties. so, my question is, is it time for me to retire and leave this theatre? Or is there hope? tx, John Tucker ----- Original Message ----- From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Friday, September 4, 2009 6:53 am Subject: Re: Best Practices for Establishing Namespace Name To: "Tsao, Scott" <scott.tsao@boeing.com> Cc: "G. Ken Holman" <gkholman@CraneSoftwrights.com>, xmlschema-dev@w3.org > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tsao, Scott writes: > > > Henry, > > > > Thanks for the confirmation! > > > > Is this the document you were referring to as far as W3C TAG's strong > > recommendation is concerned: > > ? > > Yes, although > > a) It has not yet been officially adopted as a TAG finding; > > b) (as you can see from the date) that document has stalled, and a > shorter and simpler one is in preparation: > > > > BUT that one hasn't been adopted yet either, so it's not suitable > to point to it as the TAG's settled position. . . > > If you find the discussion in either of those documents helpful, > great, but just be careful to cite them as work-in-progress, if at > all. > > ht > - -- > Henry S. Thompson, School of Informatics, University of Edinburgh > Half-time member of W3C Team > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: > [mail really from me _always_ has this .sig -- mail without it is > forged spam] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFKoPEfkjnJixAXWBoRAmDmAJ9Z/KvDbmcxKZlTQW00oHQ1QDIFIgCdGB3X > VqTqXtC1ho4o8qfdhfpJybQ= > =9bje > -----END PGP SIGNATURE----- >]]> http://www.altova.com/list/xmlschema-dev/200909/msg1000302537.html