http://www.stylusstudio.com/blogs/schemadev/XML Schema-DEV is an open, un-moderated email list about W3C XML Schema (XSD) development issues, including XML Schema tools, tutorials, specifications, syntax, data modeling, and more. Learn XML Schema with free resources from the XMLSCHEMA-DEV Blog today. Copyright 2004-2006 Progress Software Corporation. All Rights Reserved.5 (If the maintainer of http://www.w3.org/XML/Schema#Tools would be so kind as to add the link to PyXB's home page, I'd appreciate it. Thanks.) PyXB version 1.0.0 is now available from SourceForge at: http://sourceforge.net/projects/pyxb/ PyXB (Python XML Schema Bindings; "pixbee") is a pure Python package that generates Python source code for classes that correspond to data structures defined by XMLSchema. In concept it is similar to JAXB for Java and CodeSynthesis XSD for C++. The current release supports XML Schema 1.0. Version 1.0.0 is feature-complete and suitable for production development where validation of incoming and generated documents is desired. The following schema constructs are supported: * Class constants corresponding to string enumeration constraints * Simple and complex type definitions * List and union datatypes * Constraints on (simple) datatypes (e.g., minInclusive, length) * Model groups and attribute groups * Complex content models (all, sequence, choice); minOccurs and maxOccurs * Abstract types, xsi:type, substitution groups * Nillable elements with xsi:nil * Namespace qualified attributes and elements * Documentation annotations present in the schema are converted to Python docstrings in the generated bindings. * Pattern constraints (as long as the simple type derives from something that is represented as a Python string) The full distribution includes generated bindings for twenty-three namespaces related to web services (including several versions of SOAP and WSDL), and twenty-eight namespaces from the Open Geospatial Consortium's Geographic Information System schema. For further information and links to the support forum and mailing list, please consult the documentation available at: http://pyxb.sourceforge.net/ Peter Received on Thursday, 19 November 2009 10:39:57 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post00001.htmWed, 18 Nov 2009 17:03:52 GMT Hi Folks, In XSD 1.1 vendors are allowed to extend the language with additional (vendor-unique) datatypes and facets. Example: In some countries the decimal point symbol is the comma; so a vendor may provide a new decimal datatype and a new facet for specifying the decimal point symbol: <xs:simpleType name="money"> <xs:restriction base="vendor:decimal"> <vendor:delimiter value="," /> <xs:restriction> </xs:simpleType> This is very useful. However, this capability represents an uncertainty in what things are in the language ("If you're using this XSD 1.1 tool then these x,y,z things are in the language, if you're using that XSD 1.1 tool then these a,b,c things are in the language"). For some of my clients: uncertainty = risk For those clients, risk must be mitigated. Thus, I issue a plea to all XSD 1.1 vendors: please provide a switch to turn on/off vendor-unique extensions. I believe that providing a switch to turn on/off vendor-unique extension will give vendors a market advantage. Thanks for your time. /Roger Received on Wednesday, 18 November 2009 20:30:23 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post09000.htmWed, 18 Nov 2009 15:29:49 GMT Thanks Henry. Just done. As I know the WG is not looking for extra work I thought I'd post to the public list so that members have a low procedure way to object to the comment if I've really missed the point! That said, I think it's a simple and useful change to make. Thanks again, 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: "Henry S. Thompson" <ht@inf.ed.ac.uk> To: "Pete Cordell" <petexmldev@codalogic.com> Cc: <xmlschema-dev@w3.org> Sent: Wednesday, November 11, 2009 9:40 AM Subject: Re: Naming in Override Constraints and Semantics -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Requests for changes to the spec should go to www-xml-schema-comments@w3.org or into Buzilla -- they may get overlooked if they are only sent here. I'd suggest you reduce the length of your requested new names, to, say, Dold and Dnew. . . 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) iD8DBQFK+oaRkjnJixAXWBoRAjCyAJ9xWKNKnDOdCgsVHifHkSH+r5oDdwCcCsMy 6PycvCIKjDgwQwoHHLQRtSM= =045d -----END PGP SIGNATURE----- Received on Wednesday, 11 November 2009 15:02:48 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post08000.htmWed, 11 Nov 2009 15:02:12 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Requests for changes to the spec should go to www-xml-schema-comments@w3.org or into Buzilla -- they may get overlooked if they are only sent here. I'd suggest you reduce the length of your requested new names, to, say, Dold and Dnew. . . 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) iD8DBQFK+oaRkjnJixAXWBoRAjCyAJ9xWKNKnDOdCgsVHifHkSH+r5oDdwCcCsMy 6PycvCIKjDgwQwoHHLQRtSM= =045d -----END PGP SIGNATURE----- Received on Wednesday, 11 November 2009 09:41:13 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post07000.htmWed, 11 Nov 2009 09:40:29 GMT In "Schema Representation Constraint: Override Constraints and Semantics", is there any chance that: - D1 could be changed to Doverridden and - D2 could be changed to Doverriding? Then: 2 One of the following must be true: 2.1 D2 has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of D1 (which must have such an [attribute]). 2.2 Neither D2 nor D1 have a targetNamespace [attribute]. 2.3 D2 has no targetNamespace [attribute] (but D1 does). becomes: 2 One of the following must be true: 2.1 Doverriding has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of Doverridden (which must have such an [attribute]). 2.2 Neither Doverriding nor Doverridden have a targetNamespace [attribute]. 2.3 Doverriding has no targetNamespace [attribute] (but Doverridden does). This is a lot easier on the old brain! There are possibly similar name changes that could be made that would make the life of the reader much easier. Thanks, 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 ============================================= Received on Tuesday, 10 November 2009 17:58:55 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post06000.htmTue, 10 Nov 2009 17:57:56 GMT 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. Received on Saturday, 7 November 2009 22:26:09 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post05000.htmSat, 07 Nov 2009 14:24:52 GMT > (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 Received on Saturday, 7 November 2009 10:25:46 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post04000.htmSat, 07 Nov 2009 10:25:13 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The spec doesn't provide a mechanism by which a schema can constrain the document element of schema-valid documents. It _does_ provide license for conformant processors to do schema-validity assessment with such a constraint in place [1]. Different processors allow users to invoke this kind of processing in different ways -- what validator are you using? ht [1] http://www.w3.org/TR/xmlschema-1/#c-res - -- 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) iD8DBQFK9Hp/kjnJixAXWBoRAkmzAJ4q7YYJ84l6UmdhZ+gdbrpNdEr9BwCeIxS/ EM49iXoq0GTVWxYb0Vv+bQI= =muE/ -----END PGP SIGNATURE----- Received on Friday, 6 November 2009 19:36:17 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post02000.htmFri, 06 Nov 2009 19:35:27 GMT 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 **************************************************************** Received on Saturday, 7 November 2009 00:35:51 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post03000.htmFri, 06 Nov 2009 17:35:19 GMT 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. > Received on Friday, 6 November 2009 19:32:40 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post01000.htmFri, 06 Nov 2009 14:30:11 GMT 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. Received on Friday, 6 November 2009 18:52:00 GMT ]]>http://xsd.stylusstudio.com/2009Nov/post00000.htmThu, 05 Nov 2009 22:58:55 GMT 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. Received on Thursday, 29 October 2009 19:39:06 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09005.htmThu, 29 Oct 2009 15:38:25 GMT -----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----- Received on Monday, 26 October 2009 14:54:41 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07005.htmMon, 26 Oct 2009 14:52:05 GMT 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/ Received on Monday, 26 October 2009 14:21:16 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06005.htmMon, 26 Oct 2009 14:20:39 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Kay writes: > 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". At the time the spec. was written, the community was pretty evenly divided between people who thought the attribute model (i.e. not in a namespace as such) was right for leaf node elements as well, and those who thought that all elements should be qualified. 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. 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) iD8DBQFK5Y5ekjnJixAXWBoRAh2UAJ4gBVgrOq4C+DK22kFTJNRvnLkSFwCfZnsJ jgNXeNgag92u+CLvC5gXK9o= =yYHE -----END PGP SIGNATURE----- Received on Monday, 26 October 2009 11:57:06 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05005.htmMon, 26 Oct 2009 11:56:14 GMT 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----- Received on Monday, 26 October 2009 15:23:04 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08005.htmMon, 26 Oct 2009 11:22:14 GMT 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/ Received on Sunday, 25 October 2009 22:40:11 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04005.htmSun, 25 Oct 2009 22:39:37 GMT > 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 Received on Sunday, 25 October 2009 18:51:50 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03005.htmSun, 25 Oct 2009 18:51:17 GMT 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/ Received on Sunday, 25 October 2009 18:06:15 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02005.htmSun, 25 Oct 2009 18:05:41 GMT 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 > > > > Received on Thursday, 22 October 2009 14:20:56 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01005.htmThu, 22 Oct 2009 10:18:39 GMT > > 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 Received on Thursday, 22 October 2009 08:08:58 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00005.htmThu, 22 Oct 2009 09:08:12 GMT 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 **************************************************************** Received on Thursday, 22 October 2009 00:12:20 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09004.htmWed, 21 Oct 2009 18:11:48 GMT 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 Received on Wednesday, 21 October 2009 21:24:11 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08004.htmWed, 21 Oct 2009 17:22:02 GMT 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 > Received on Tuesday, 20 October 2009 19:34:05 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07004.htmTue, 20 Oct 2009 22:33:32 GMT 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 Received on Tuesday, 20 October 2009 17:14:09 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06004.htmTue, 20 Oct 2009 10:51:47 GMT 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 Received on Tuesday, 20 October 2009 08:27:15 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05004.htmTue, 20 Oct 2009 09:26:40 GMT 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 Received on Tuesday, 20 October 2009 07:07:48 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04004.htmTue, 20 Oct 2009 09:07:09 GMT 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 Received on Tuesday, 20 October 2009 01:07:01 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03004.htmMon, 19 Oct 2009 18:06:26 GMT 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. > > > > > > > > Received on Monday, 19 October 2009 15:22:47 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01004.htmMon, 19 Oct 2009 17:22:12 GMT 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. > > > Received on Monday, 19 October 2009 16:01:54 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02004.htmMon, 19 Oct 2009 16:57:10 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Kay writes: >> ... 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. And what XSV does -- it is necessary to do this to ensure multiple chameleon includes into different namespaces works properly. 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) iD8DBQFK3DofkjnJixAXWBoRAmnlAJ9I6XnNvI5W6qSgTPvVOqzLg84aWgCfbYYy lXbIHxYFMPnudei1X12a7IQ= =F8lC -----END PGP SIGNATURE----- Received on Monday, 19 October 2009 10:06:58 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00004.htmMon, 19 Oct 2009 11:06:23 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Kay writes: > 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. I agree that this is the best available interpretation. > 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. I agree again. > 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. Right -- a useful analysis, thanks. 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) iD8DBQFK3DkzkjnJixAXWBoRAj1IAJ9CVgigXB3xQfzTe9x2OeTovT3E6QCfQNmG VvXucWnVMMi+LG/RifrT8c4= =xFVQ -----END PGP SIGNATURE----- Received on Monday, 19 October 2009 10:02:59 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09003.htmMon, 19 Oct 2009 11:02:27 GMT 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. > > > Received on Sunday, 18 October 2009 22:28:24 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08003.htmSun, 18 Oct 2009 23:27:50 GMT 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. Received on Sunday, 18 October 2009 21:30:47 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07003.htmSun, 18 Oct 2009 03:31:44 GMT > -----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 Received on Friday, 16 October 2009 21:22:41 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05003.htmFri, 16 Oct 2009 22:22:09 GMT > 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 Received on Friday, 16 October 2009 20:12:32 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03003.htmFri, 16 Oct 2009 21:11:58 GMT 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 Received on Friday, 16 October 2009 21:58:03 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06003.htmFri, 16 Oct 2009 17:57:20 GMT 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 Received on Friday, 16 October 2009 20:35:59 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04003.htmFri, 16 Oct 2009 16:35:06 GMT 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 Received on Friday, 16 October 2009 19:00:04 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02003.htmFri, 16 Oct 2009 14:59:13 GMT > 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 Received on Friday, 16 October 2009 13:30:19 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01003.htmFri, 16 Oct 2009 14:29:34 GMT > 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 Received on Monday, 12 October 2009 20:05:28 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09002.htmMon, 12 Oct 2009 21:04:47 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Kay writes: > 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. Yes, that sounds right. > A similar approach might also work reliably for "chameleon include". Includes in general are less problematic, as there is no option for processors -- they _must_ process the nominated schema document. > But better advice is not to use redefine or chameleon include. 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. . . 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) iD8DBQFK04WokjnJixAXWBoRAsvbAJ9nerp4yckxN4iPts1pBBDyZvyalgCaAzfm mGqLLD1JN8IMkIsAynGy96k= =Ot+l -----END PGP SIGNATURE----- Received on Monday, 12 October 2009 19:38:48 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08002.htmMon, 12 Oct 2009 20:38:15 GMT 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 **************************************************************** Received on Tuesday, 13 October 2009 00:02:41 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00003.htmMon, 12 Oct 2009 18:02:10 GMT 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----- > Received on Monday, 12 October 2009 16:48:52 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06002.htmMon, 12 Oct 2009 17:48:09 GMT -----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----- Received on Monday, 12 October 2009 15:40:18 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05002.htmMon, 12 Oct 2009 16:39:33 GMT 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> Received on Monday, 12 October 2009 17:01:11 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07002.htmMon, 12 Oct 2009 13:00:39 GMT 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 Received on Friday, 9 October 2009 09:07:13 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04002.htmFri, 09 Oct 2009 11:05:50 GMT 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 Received on Friday, 9 October 2009 08:36:28 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02002.htmFri, 09 Oct 2009 10:35:50 GMT 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 Received on Friday, 9 October 2009 09:03:30 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03002.htmFri, 09 Oct 2009 10:02:46 GMT 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 Received on Friday, 9 October 2009 08:33:29 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01002.htmFri, 09 Oct 2009 09:32:39 GMT 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 Received on Thursday, 8 October 2009 10:07:20 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06001.htmThu, 08 Oct 2009 13:06:47 GMT 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 Received on Thursday, 8 October 2009 10:12:59 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09001.htmThu, 08 Oct 2009 12:12:26 GMT 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 Received on Thursday, 8 October 2009 10:11:46 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08001.htmThu, 08 Oct 2009 12:11:11 GMT 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 Received on Thursday, 8 October 2009 10:07:43 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07001.htmThu, 08 Oct 2009 11:07:01 GMT 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 > Received on Thursday, 8 October 2009 13:27:01 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00002.htmThu, 08 Oct 2009 09:24:59 GMT 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 Received on Thursday, 8 October 2009 09:46:49 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05001.htmWed, 07 Oct 2009 18:10:30 GMT 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 Received on Tuesday, 6 October 2009 20:47:48 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03001.htmTue, 06 Oct 2009 16:45:50 GMT 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 **************************************************************** Received on Tuesday, 6 October 2009 22:41:19 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04001.htmTue, 06 Oct 2009 16:40:46 GMT 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. Received on Monday, 5 October 2009 11:57:51 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02001.htmMon, 05 Oct 2009 12:57:12 GMT > > 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 Received on Saturday, 3 October 2009 16:11:50 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00001.htmSat, 03 Oct 2009 17:11:12 GMT 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 Received on Saturday, 3 October 2009 16:31:26 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01001.htmSat, 03 Oct 2009 12:30:48 GMT 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 >> > -------------------------------------- >> > >> > >> > >> > >> > >> > >> > >> > > Received on Saturday, 3 October 2009 10:14:47 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post08000.htmSat, 03 Oct 2009 12:13:54 GMT 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 >> > -------------------------------------- >> > >> > >> > >> > >> > >> > >> > >> > > Received on Saturday, 3 October 2009 15:19:18 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post09000.htmSat, 03 Oct 2009 11:18:38 GMT 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 > -------------------------------------- > > > > > > > Received on Friday, 2 October 2009 22:10:45 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post06000.htmSat, 03 Oct 2009 11:09:56 GMT 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 > > -------------------------------------- > > > > > > > > > > > > > > > Received on Friday, 2 October 2009 22:44:33 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post07000.htmFri, 02 Oct 2009 23:43:49 GMT 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 Received on Friday, 2 October 2009 15:59:52 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post05000.htmFri, 02 Oct 2009 11:57:54 GMT 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 Received on Friday, 2 October 2009 07:20:04 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post04000.htmFri, 02 Oct 2009 09:19:21 GMT 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 Received on Thursday, 1 October 2009 22:54:13 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post03000.htmThu, 01 Oct 2009 23:53:20 GMT > 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 Received on Thursday, 1 October 2009 22:45:15 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post02000.htmThu, 01 Oct 2009 23:44:17 GMT 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 Received on Thursday, 1 October 2009 15:49:33 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post00000.htmThu, 01 Oct 2009 17:57:05 GMT 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 Received on Thursday, 1 October 2009 15:54:46 GMT ]]>http://xsd.stylusstudio.com/2009Oct/post01000.htmThu, 01 Oct 2009 11:54:04 GMT 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 Received on Wednesday, 30 September 2009 17:09:13 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post02003.htmWed, 30 Sep 2009 13:07:19 GMT -----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----- Received on Tuesday, 29 September 2009 14:48:07 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post08002.htmTue, 29 Sep 2009 15:47:32 GMT 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/ Received on Tuesday, 29 September 2009 13:14:15 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post07002.htmTue, 29 Sep 2009 14:13:35 GMT 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 Received on Tuesday, 29 September 2009 12:31:00 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post06002.htmTue, 29 Sep 2009 13:24:13 GMT 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 -------------------------------------- Received on Tuesday, 29 September 2009 16:55:27 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post01003.htmTue, 29 Sep 2009 12:57:14 GMT 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----- > > Received on Tuesday, 29 September 2009 16:08:05 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post00003.htmTue, 29 Sep 2009 11:07:20 GMT On 29 Sep 2009, at 05:24 , XMLSchema at XML4Pharma wrote: > We, the CDISC XML-Tech Governance Team (and other CDISC teams) have > developed a number of extensible standards for exchange of clinical > data and for submitting information to the regulatory authorities > (FDA). > > CDISC is a Standardization Organization active in the healthcare > world. > > Our extension mechanism is based on the “import” and “redefine” > elements of XML-Schema. > > We now have a serious dispute with one technology vendor (Altova) > about the way “import” and “redefine” are used. Instance files of > one of our extensions (so-called “define.xml”) validate well in all > major validators and XML-editors, except for the products of this > one vendor. > > When confronted with this result, the reaction of Altova essentially > is that “Altova is right, all others are wrong”. The dispute and > discussion with Altova can be followed at: > http://www.altova.com/forum/default.aspx?g=posts&m=1000005665 > > The issue were not so serious if it were not that our standard > “define.xml” is a standard for submission of information to the > regulatory authorities, and these are (mostly) using the Altova > product for validation. > > We now want to escalate the issue to the W3C itself, and would like > to know what the mechanism is to do so. > > Jozef Aerts > CDISC XML-Tech Governance Team > I believe that some standards bodies have mechanisms for requesting authoritative interpretations of doubtful points in specifications published by those bodies. W3C does not have any formal mechanism for such interpretations, but you can certainly request an opinion from the W3C XML Schema Working Group by sending mail to the XSD comments list at www-xml-schema-comments@w3.org (or by raising a Bugzilla issue against XSD 1.0). The public record shows, however, that the XML Schema Working Group has already addressed the question of what happens when the same schema document is referred to both by a direct import or include and indirectly through a reference to another schema document which redefines the first (see Bugzilla bugs 2330, 2557, 2824, and on related issues also 2826 and 5425, in the W3C public instance of Bugzilla at http://www.w3.org/Bugs/Public/). As the record shows, the Working Group has been unable to resolve those issues in part because the group has not been able to reach consensus on the meaning of the 1.0 specification in the cases in question. Reviewing the discussion record on the Altova forum I am struck by the repeated remark that the CDISC team has consulted "several distinguished members of the W3C XML-Schema working group" who confirmed CDISC's interpretation of the XSD 1.0 spec. I can only hope that these consultations took place some years ago, before the working group realized just how divergent its interpretations of the specification are; if you have consulted with any member of the working group in the last four years about this case, and they have failed to mention to you that the spec invites multiple contradictory interpretations, and that the working group has been unable to agree on what a single interpretation, then I fear they have misled you sadly. I'm also struck by the report that XML Spy is an outlier in its behavior on this case. The work I did in 2007 on an analogous case suggested that depending on how they were invoked, the eight processors tested behaved in nine or ten different ways (fourteen if you count error messages reporting different diagnoses of the problem as different behaviors). The work is described in a document available at http://www.cmsmcq.com/2007/schema_composition/model.xml (the test cases which elicit these different behaviors are described in section 5.2.2 and its subsctions). The XSD 1.0 specification does not explicitly address the case when the same schema document in referenced both directly (via import or include) and indirectly (via redefine). The rules for import specify that the components imported via the import or include should be present in the resulting schema; the discussion of redefine says that the effect of redefine is pervasive. Some readers interpret this to mean that the pervasive-redefinition rule overrides, or modifies the effect of, the import and include rules. On this reading the schema is legal and the components are present in their redefined form (and only that form). This reading effectively attaches to the rules for include and import an unspoken exception to the effect that the components imported or included are present in the resulting schema unless they are redefined by some other schema document reference. Other readers interpret the rules as requiring that the components in question should be present both in their original and in their redefined form, which means that the schema violates the rule that there must be at most one component of any kind with a given expanded name, and thus that the schema should be rejected. It is my personal belief that the most plausible interpretation of the specification is the latter; as you have observed, at least some implementors disagree and prefer the other interpretation. The inability of the XML Schema working group to agree on a normative interpretation of XSD 1.0 has led to the agreement to deprecate the redefine element in XSD 1.1. My personal recommendation is either to avoid redefine entirely or to avoid the use of schemaLocation information in your primary schema documents, restricting the identification of specific schema documents to top-level 'driver' documents, or to invocation-time parameters and options passed to the validator. I hope this helps. Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** Received on Tuesday, 29 September 2009 15:58:34 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post09002.htmTue, 29 Sep 2009 09:57:53 GMT 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@j...> > > > > > > "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 > Received on Tuesday, 22 September 2009 18:44:44 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post05002.htmTue, 22 Sep 2009 14:44:04 GMT 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----- > Received on Tuesday, 8 September 2009 19:59:58 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post04002.htmTue, 08 Sep 2009 15:59:16 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 XML4Pharma writes: > [positive about XML Schema 1.1] Thanks for the encouraging words! > Speaking about MS parsers. Is there any news there about future > support by Microsoft for XML-Schema 1.1? E.g. are there any .Net > validating parsers in development ? MS respond to customer input on things like this -- get your pharma industry colleagues to tell their MS account rep. that they want XML Schema 1.1, and that will help make it happen. 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) iD8DBQFKpOrakjnJixAXWBoRApcxAJ9AwbZXU9y/BvDZIpFziDxnrw2d4gCfbnns JRJq9q9JnRbBWLK+bmySp0M= =/qcl -----END PGP SIGNATURE----- Received on Monday, 7 September 2009 11:14:08 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post03002.htmMon, 07 Sep 2009 12:13:30 GMT Hello Roger, As usual, a brilliant description from you, as shared at the URL given by you :) I'll be reading the presentation you wrote, in the next few days, and may post any thoughts I might have. I would like to share, that Apache Xerces-J is also working on XML Schema 1.1 implementation. I just wrote a blog post, about this at, http://mukulgandhi.blogspot.com/2009/09/roger-l-costello-xml-schema-11.html. On Sat, Sep 5, 2009 at 8:08 PM, Costello, Roger L. <costello@mitre.org> wrote: > > Hi Folks, > > I created a tutorial, for managers, on XML Schema 1.1. > > Its purpose is to give an overview of the new features of XML Schema 1.1, without getting into its syntax, and to show how the new features can benefit a business. > > http://www.xfront.com/xml-schema-1-1/xml-schema-1-1-for-managers.ppt > > Comments welcome. > > /Roger -- Regards, Mukul Gandhi Received on Saturday, 5 September 2009 17:56:17 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post01002.htmSat, 05 Sep 2009 23:25:18 GMT Excellent stuff ! I have passed it to the other team members of our CDISC "XML Governance Team" (CDISC provides XML-based standards for use in clinical research). Together with the information that Apache Xerces-J is working on an implementation, this might mean that we move all our schemas to version 1.1 early next year. Our standards will highly benefit from this as: - a good number of the rules in our standards can currently not be expressed with XML-Schema 1.0, but they can with Schematron, so moving to 1.1 is a "great step for mankind" - our extensions use xsd:redefine which is not (correctly) supported by XMLSpy (but is by most other validators). This causes a problem as some authorities like the FDA have standardized on XMLSpy. Presume (but haven't looked into yet) that "override" is more powerful. Hope that XMLSpy will support that. Speaking about MS parsers. Is there any news there about future support by Microsoft for XML-Schema 1.1? E.g. are there any .Net validating parsers in development ? Best regards, Jozef Aerts CDISC volunteer ----- Original Message ----- From: "Costello, Roger L." <costello@mitre.org> To: <xmlschema-dev@w3.org> Sent: Saturday, September 05, 2009 4:38 PM Subject: ANN: XML Schema 1.1 for Managers Hi Folks, I created a tutorial, for managers, on XML Schema 1.1. Its purpose is to give an overview of the new features of XML Schema 1.1, without getting into its syntax, and to show how the new features can benefit a business. http://www.xfront.com/xml-schema-1-1/xml-schema-1-1-for-managers.ppt Comments welcome. /Roger Received on Saturday, 5 September 2009 18:52:02 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post02002.htmSat, 05 Sep 2009 20:51:16 GMT Hi Folks, I created a tutorial, for managers, on XML Schema 1.1. Its purpose is to give an overview of the new features of XML Schema 1.1, without getting into its syntax, and to show how the new features can benefit a business. http://www.xfront.com/xml-schema-1-1/xml-schema-1-1-for-managers.ppt Comments welcome. /Roger Received on Saturday, 5 September 2009 14:39:18 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post00002.htmSat, 05 Sep 2009 10:38:42 GMT -----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: > http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 ? 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: http://www.w3.org/2001/tag/doc/justSayHTTP.html 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: 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) iD8DBQFKoPEfkjnJixAXWBoRAmDmAJ9Z/KvDbmcxKZlTQW00oHQ1QDIFIgCdGB3X VqTqXtC1ho4o8qfdhfpJybQ= =9bje -----END PGP SIGNATURE----- Received on Friday, 4 September 2009 10:51:56 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post09001.htmFri, 04 Sep 2009 11:51:11 GMT Henry, Thanks for the confirmation! Is this the document you were referring to as far as W3C TAG's strong recommendation is concerned: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 ? Scott -----Original Message----- From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] Sent: Wednesday, September 02, 2009 2:40 AM To: Tsao, Scott Cc: G. Ken Holman; xmlschema-dev@w3.org Subject: Re: Best Practices for Establishing Namespace Name -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > And, is the use of them for namespace names (in lieu of URN) > recommended by standards organizations such as W3C and OASIS? Absolutely. OASIS have backed off using URNs as namespace names, and W3C TAG strongly recommends using http: URIs for this purpose. ... 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) iD8DBQFKnj1akjnJixAXWBoRAgpnAJ946RWeMWRT4NA3S1hHT0bCc63GPgCcDCJp 3NNY0Glqx4E0BJeWcEZs0z8= =zpxU -----END PGP SIGNATURE----- Received on Thursday, 3 September 2009 23:40:42 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post08001.htmThu, 03 Sep 2009 16:39:45 GMT > Simon Cox writes: >> A processors will maintain a cache of schema component definitions and >> declarations and associate it with a namespace. Ah I can see where the confusion would come from : ) and why it then seemed to make sense (or be a requirement in fact) to change the namespace between versions so that you could process multiple versions with the same schema processor. In 1.1 I think you can switch types based on a version attribute, so you could in fact validate multiple versions of the xml with a single schema. something like: <xs:element name="root" type="root"> <xs:alternative type="root-version-1" test="@version = '1.0'"/> <xs:alternative type="root-version-1-1" test="@version = '1.1'"/> </xs:element> -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Thursday, 3 September 2009 09:01:26 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post06001.htmThu, 03 Sep 2009 10:00:45 GMT Andrew says 'Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser'. From the perspective of automated processing of XML this is beside the point. A program processing XML does not look at snippets of markup (and anyway the prefix is not defined by the schema and in a "snippet" without namespace bindings the prefix has no meaning). If a namespace relates to a particular version of a schema, it provides an unambiguous indication of which schema should be used by a processor. If a version attribute has to be considered as well, the processor needs some knowledge of the convention used for versioning within that particular namespace. For this there is no standard. This email chain has brought into new focus a concern I had about the rationale for the Schema 1.1 "Open Content" enhancements. There is an implied expectation behind these that schemas will change without any change in their namespace, and this is arguably not "best practice", since it implies a non-standard versioning mechanism. The idea behind these enhancements is that a message producer can move to a "Level 2" version of a schema, which defines more precisely what in the "Level 1" version would have been possible by use of wildcards, whilst message consumers who are unaware of "Level 2" can continue to process messages from such producers. If the namespace were to change as part of the move from "Level 1" to "Level 2" the intention of the enhancements (that some consumers can remain unaware of the change) would be defeated. I think there is an important consideration that if there many bodies producing messages some may move to "Level 2" while others are at "Level 1". A message consumer may be aware of both "Level 1" and "Level 2" versions of the schema and may need to know which version to apply when processing a message received, e.g., for either or both of the following reasons: (a) The set of messages acceptable under "Level 2" may be smaller than that acceptable under "Level 1". If the processor is responsible for validation, it needs to know which level to use for validation. (b) Typically a "Level 2" schema will have been a response to a need to communicate additional information, and it is a common situation that de facto this information was being sent between parties by means of wildcards under "Level 1". It is likely that the convention for this would not correspond exactly to the formal definitions introduced in "Level 2". Therefore the processor may have to look in different places to find equivalent information depending on which version of the schema the message producer was using. Therefore to be used in an environment where messages are produced by multiple parties and are processed automatically by recipients, the "open content" enhancements imply that some kind of version attribute is available to processors, and to my mind it is a weakness that the schema standard implies versioning changes within a namespace without defining or even mentioning how versioning can be communicated if not by namespace change. Or putting this more strongly, it could be argued that the "open content" enhancements are predicated on "bad practice" in terms of URN assignment. Pete -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Andrew Welch Sent: 02 September 2009 16:54 Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiserDisclaimer: 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. Received on Thursday, 3 September 2009 09:39:02 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post07001.htmThu, 03 Sep 2009 09:10:56 GMT Also forwarded to the list as this is likely to be of general interest. -----Original Message----- From: Simon Cox [mailto:simon.cox@j...] Sent: Wednesday, 2 September 2009 20:06 To: 'noah_mendelsohn@us.ibm.com' Cc: 'Andrew Welch'; 'ekimber'; 'G. Ken Holman'; 'Henry S. Thompson'; 'Tsao, Scott' Subject: RE: Best Practices for Establishing Namespace Name Not in general, but sometimes, and often enough to matter for certain use-cases. A review of processing engines (including those built in to enterprise tools like Oracle) a few years ago led us to the conclusion that the real tools used in real organizations had diverse behaviours. OGC is in business of publishing schemas for widespread use by many organizations, used to build loosely coupled systems where it isn't feasible to enforce any particular one of the caching and processing models allowed by the spec, so we had to assume the worse case. That requirement inexorably led to the conclusion that new namespaces were required every time. This won't apply in every use case, but if you are publishing schemas that you expect lots of people to use, and you have limited control over them it is a scenario that must be considered. However, there is a nuance to this: where the new schema only adds stuff to an existing schema, you do this in a new namespace, but <import> the existing schema, so existing components do not change namespaces, its just that the ones added after the original publication have a new namespace. (Effectively this is the strategy used by Google when upgrading KML.) -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] Sent: Wednesday, 2 September 2009 19:56 To: Simon Cox Cc: 'Andrew Welch'; 'ekimber'; 'G. Ken Holman'; 'Henry S. Thompson'; 'Tsao, Scott' Subject: RE: Best Practices for Establishing Namespace Name Simon Cox writes: > A processors will maintain a cache of schema component definitions and > declarations and associate it with a namespace. Not in general. That's neither required nor encouraged by the Recommendation, though it is allowed, and some implementations do. > The processing rules in the XML Schema spec do not require that a > processor load the schema fresh if a new document comes in with the > same namespace. That's true, but neither do they forbid reloading. Quoting from the Rec: [1]: "Processors have the option to assemble (and perhaps to optimize or pre-compile) the entire schema prior to the start of an .assessment. episode, or to gather the schema lazily as individual components are required." I think your reasoning is somewhat backwards: I believe the intention is that processors may implement a variety of startegies, and that >users should choose processors (or processor switches) that are appropriate for the particular purpose<. So, rather than saying: "be sure to use a new namespace when the processing rules for your markup change between versions, because your processor will surely cache the old content models". I would say: "There are many tradeoffs in deciding whether to use the same markup from the same namespaces when content models and/or the interpretation of content changes from version to version. One complexity to consider is that some schema processors maintain caches of pre-assembled schemas, and those processors may not behave well if the same markup is to be interpreted differently according to the version of the language. Other processors do provide either for just-in-time assembly of schemas, or for the necessary level of control over schema document caching." BTW: there are really downsides to using a new namespace when minor changes are made to a language. There can be many other artifacts that will need revision that would otherwise be unnecessary, e.g. XPaths in stylesheets. Furthermore, it can happen that a new version is created to revise just one small feature of a language, and then the question arises whether to republish the whole language in a new namespace, or only the new features. If the former is done, then even documents otherwise unaffected by the language revision may wind up having two expressions, one using the old and one using the new namespace; conversely, if only changed markup is in the new namespace, then users have to remember which feature was revised when, and deal with many namespace prefixes when languages are revised many times. Overall, my observation has been that it's usually easier to use namespaces for more functional decomposition (e.g. one namespace for personnel-related vocabulary, one for inventory, etc.) and to use namespace changes sparingly when implementing revisions to a language specification. So, mostly, successive versions of a language should use the same namespaces, except maybe for qualitatively different features. Noah [1] http://www.w3.org/TR/xmlschema-1/#layer1 -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Simon Cox" <simon.cox@j...> 09/02/2009 01:34 PM To: "'Andrew Welch'" <andrew.j.welch@gmail.com> cc: <noah_mendelsohn@us.ibm.com>, "'Tsao, Scott'" <scott.tsao@boeing.com>, "'G. Ken Holman'" <gkholman@cranesoftwrights.com>, "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, <xmlschema-dev@w3.org>, "'ekimber'" <ekimber@reallysi.com> Subject: RE: Best Practices for Establishing Namespace Name No - its not merely the identity issue. It's the processing issue. A processors will maintain a cache of schema component definitions and declarations and associate it with a namespace. The processing rules in the XML Schema spec do not require that a processor load the schema fresh if a new document comes in with the same namespace. So if the new document is actually using a different schema (even if the namespace is the same) then processing will fail. The only way to ensure safe processing (i.e. that respects *all* of the processing straegies allowed for in the XML Schema spec) is to be scrupulous about changing namespace if the schema changes. In many cases that is most easily handled by including a version identifier in the namespace. Because of all this, the XML Schema processing rules effectively imply that the target namespace is the schema identifier. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: Andrew Welch [mailto:andrew.j.welch@gmail.com] Sent: Wednesday, 2 September 2009 19:18 To: Simon Cox Cc: noah_mendelsohn@us.ibm.com; Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@w3.org; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 Simon Cox <simon.cox@j...>: > Andrew Welch wrote >> use a version attribute to distinguish the versions > > Where? Typically on the root element, but it could go anywhere that's suitable. > The issue was that elements with the same name were defined > differently in both GML 2.0 and GML 3.0, But they had the same target > namespace. The differences were subtle - technical rather than > conceptual - but real as far as a validating processor is concerned. > The XML namespace is to all practical intents and purposes the > designated identifier for 'the schema' and we had the same identifier > for different things. Chaos ensues. Between versions the content model of elements will change, but that doesn't mean you need a different namespace... Incompatible changes are actually easier than supporting backwards compatibility, instead of detecting the version and using the right xsd and corresponding parsing code, you simply reject anything that fails validation for that version. Anyway, it's interesting that you say the namespace is (to all intents ands purposes) the identifier for the schema, perhaps that's where the problem is... the namespace value itself has started to mean something, when its meant to mean nothing. Everyone seems to have different opinions on this, and I think Ive asked in the past if anyone has a best practices guide which didnt attract too many confident replies, but at the moment for me its simply "namespace that won't ever change, version attribute" : ) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 18:09:40 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post04001.htmWed, 02 Sep 2009 20:08:59 GMT No - its not merely the identity issue. It’s the processing issue. A processors will maintain a cache of schema component definitions and declarations and associate it with a namespace. The processing rules in the XML Schema spec do not require that a processor load the schema fresh if a new document comes in with the same namespace. So if the new document is actually using a different schema (even if the namespace is the same) then processing will fail. The only way to ensure safe processing (i.e. that respects *all* of the processing straegies allowed for in the XML Schema spec) is to be scrupulous about changing namespace if the schema changes. In many cases that is most easily handled by including a version identifier in the namespace. Because of all this, the XML Schema processing rules effectively imply that the target namespace is the schema identifier. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: Andrew Welch [mailto:andrew.j.welch@gmail.com] Sent: Wednesday, 2 September 2009 19:18 To: Simon Cox Cc: noah_mendelsohn@us.ibm.com; Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@w3.org; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 Simon Cox <simon.cox@j...>: >  Andrew Welch wrote >> use a version attribute to distinguish the versions > > Where? Typically on the root element, but it could go anywhere that's suitable. > The issue was that elements with the same name were defined > differently in both GML 2.0 and GML 3.0, But they had the same target > namespace. The differences were subtle - technical rather than > conceptual - but real as far as a validating processor is concerned. > The XML namespace is to all practical intents and purposes the > designated identifier for 'the schema' and we had the same identifier > for different things. Chaos ensues. Between versions the content model of elements will change, but that doesn't mean you need a different namespace... Incompatible changes are actually easier than supporting backwards compatibility, instead of detecting the version and using the right xsd and corresponding parsing code, you simply reject anything that fails validation for that version. Anyway, it's interesting that you say the namespace is (to all intents ands purposes) the identifier for the schema, perhaps that's where the problem is... the namespace value itself has started to mean something, when its meant to mean nothing. Everyone seems to have different opinions on this, and I think Ive asked in the past if anyone has a best practices guide which didnt attract too many confident replies, but at the moment for me its simply "namespace that won't ever change, version attribute" : ) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 17:35:46 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post03001.htmWed, 02 Sep 2009 19:34:30 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 C. M. Sperberg-McQueen writes: > The meaning of some identifiers is given in a way that > guarantees permanence of the meaning assigned. I'm very interested in examples of this for identifiers useable on the web, particularly ones which participate in what's been informally called the 'follow your nose' property, or, per [1], "grounded in the Web": the specifications required for their interpretation should be discoverable by recursively following links starting with the specification for URIs [rfc 3986]. > If URLs mean things by virtue of the actions and/or intentions of > their owners (which is what I understand the TAG's story to be), > then when the owner changes, the meaning is necessarily subject to > change. Indeed. As I said in my previous message, diligence is required to forestall this, and it's not unreasonable to expect/mandate diligence in cases where long-term persistence is a high-level goal. > The difference at issue is not whether, when you dereference > something, you get something 'misleading' or not. The > issue is whether the prescribed methods for determinining > the denotation of an identifier guarantee stability of > denotation over time or not. > On the account offered in your email, the system of using > URLs as long-lived identifiers seems to depend on (a) the > proposition that a URL has a given meaning just when the > owner of the relevant domain assigns it that meaning, and > (b) the proposition that a URL has a given meaning > whenever we feel like interpreting that way, regardless > of the actions of the owner of the relevant domain. > > The TAG may have no trouble reconciling those two > propositions; I confess that to me, they just look like > a contradiction at the heart of the TAG's edifice. Insofar as the TAG is in a position to prescribe anything in this area, (1) is indeed the official story (actually, it's RFC 3986 which _prescribes_ in this case). Your (2) is a lot stronger than what I said, which was in any case _not_ a TAG position, or even anyone's proposal of a _possible_ position, but rather an empirical _claim_, with respect to a small number of very widely deployed namespace URIs. _If_ that claim is true, that means that the world is not behaving as has been 'prescribed'. There is in fact a lively debate underway about a variety of possible accounts of URIs and how they identify things, which may or may not succeed in reconciling theory and practice in a useful way. The relevance of all this to the issue at hand is, I think, not very great. As long as the purpose of creating namespace URIs at all involves a) at least the possibility of value-add from web-access via the namespace URI; b) a commitment to diligence wrt any registrations which underlie whatever web-access mechanisms are in prospect. then my advice stands -- http: URIs have a clear advantage over any other form of URI. ht [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html - -- 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) iD8DBQFKnrh2kjnJixAXWBoRAixbAJ9zvrSVB2lcfHZLCS0ps9/kG18XxgCdFBlA qop9GJB3IifZ9Lz4iHR1ekQ= =6IOi -----END PGP SIGNATURE----- Received on Wednesday, 2 September 2009 18:26:01 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post05001.htmWed, 02 Sep 2009 19:24:54 GMT I agree with Michael. The fact that there is no general URN resolution service (besides reading the relevant RFCs) is highly inconvenient and pragmatically it is a killer. But the fact that URN assignment is onerous (much much much more onerous than URL creation) is not necessarily a bad thing. Some resources really are more valuable than others, and having a high threshold in the identifier assignment process reinforces this. I think I understand the Thompson/TAG argument that the same discipline *could* be applied to http URIs, but in general it is not ... which leaves us in this maybe/maybe not situation. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of C. M. Sperberg-McQueen Sent: Wednesday, 2 September 2009 18:53 To: Henry S. Thompson Cc: C. M. Sperberg-McQueen; Tsao, Scott; G. Ken Holman; xmlschema-dev@w3.org Subject: Re: Best Practices for Establishing Namespace Name On 2 Sep 2009, at 09:40 , Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > C. M. Sperberg-McQueen writes: > >> The record would not be complete without someone observing that it >> also has the disadvantage that if the domain name registration for >> [your committee] ever lapses, there is no guarantee that the new >> owner will refrain from assigning a new meaning to http://[your >> committee]/namespaces/xxx > > For sure. > > But be careful using this as an argument in favour of using URNs or > some other URI scheme -- If you don't care about dereferencing, it > doesn't matter that http://[your committee]/namespaces/xxx doesn't > dereference today, and might dereference misleadingly in some > relatively unlikely future. If you _do_ care, then the mechanisms put > in place to support dereferencing of e.g. URNs will almost certainly > be vulnerable to the same human-originating failure modes. The meaning of some identifiers is given in a way that guarantees permanence of the meaning assigned. If URLs mean things by virtue of the actions and/or intentions of their owners (which is what I understand the TAG's story to be), then when the owner changes, the meaning is necessarily subject to change. The difference at issue is not whether, when you dereference something, you get something 'misleading' or not. The issue is whether the prescribed methods for determinining the denotation of an identifier guarantee stability of denotation over time or not. On the account offered in your email, the system of using URLs as long-lived identifiers seems to depend on (a) the proposition that a URL has a given meaning just when the owner of the relevant domain assigns it that meaning, and (b) the proposition that a URL has a given meaning whenever we feel like interpreting that way, regardless of the actions of the owner of the relevant domain. The TAG may have no trouble reconciling those two propositions; I confess that to me, they just look like a contradiction at the heart of the TAG's edifice. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** Received on Wednesday, 2 September 2009 17:04:40 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post01001.htmWed, 02 Sep 2009 19:03:07 GMT 2009/9/2 Simon Cox <simon.cox@j...>: >  Andrew Welch wrote >> use a version attribute to distinguish the versions > > Where? Typically on the root element, but it could go anywhere that's suitable. > The issue was that elements with the same name were defined differently in > both GML 2.0 and GML 3.0, > But they had the same target namespace. The differences were subtle - > technical rather than conceptual - but real as far as a validating processor > is concerned. The XML namespace is to all practical intents and purposes the > designated identifier for 'the schema' and we had the same identifier for > different things. Chaos ensues. Between versions the content model of elements will change, but that doesn't mean you need a different namespace... Incompatible changes are actually easier than supporting backwards compatibility, instead of detecting the version and using the right xsd and corresponding parsing code, you simply reject anything that fails validation for that version. Anyway, it's interesting that you say the namespace is (to all intents ands purposes) the identifier for the schema, perhaps that's where the problem is... the namespace value itself has started to mean something, when its meant to mean nothing. Everyone seems to have different opinions on this, and I think Ive asked in the past if anyone has a best practices guide which didnt attract too many confident replies, but at the moment for me its simply "namespace that won't ever change, version attribute" : ) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 17:18:37 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post02001.htmWed, 02 Sep 2009 18:17:56 GMT Andrew Welch wrote > use a version attribute to distinguish the versions Where? The issue was that elements with the same name were defined differently in both GML 2.0 and GML 3.0, But they had the same target namespace. The differences were subtle - technical rather than conceptual - but real as far as a validating processor is concerned. The XML namespace is to all practical intents and purposes the designated identifier for 'the schema' and we had the same identifier for different things. Chaos ensues. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Andrew Welch Sent: Wednesday, 2 September 2009 17:54 To: Simon Cox Cc: noah_mendelsohn@us.ibm.com; Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@w3.org; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 Simon Cox <simon.cox@j...>: > In some situations it is good to include dates or version numbers in > namespace names. > For example, if your maintenance/governance arrangement expects new > versions, and particularly if the new versions are not compatible with > older versions. > Geography Markup Language from OGC made the mistake of keeping the > same XML namespace for several incompatible versions of GML, and this > has caused confusion. (The policy has since been fixed). > > Of course, you can choose to give your new version a completely new > name and namespace, but sometimes you want to claim continuity, or at > least a common scope, with an earlier product, but not confuse > processors by having incompatible declarations in the same target namesapce. Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 16:08:53 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post09000.htmWed, 02 Sep 2009 18:03:51 GMT In some situations it is good to include dates or version numbers in namespace names. For example, if your maintenance/governance arrangement expects new versions, and particularly if the new versions are not compatible with older versions. Geography Markup Language from OGC made the mistake of keeping the same XML namespace for several incompatible versions of GML, and this has caused confusion. (The policy has since been fixed). Of course, you can choose to give your new version a completely new name and namespace, but sometimes you want to claim continuity, or at least a common scope, with an earlier product, but not confuse processors by having incompatible declarations in the same target namesapce. There are no universal rules here - you need to be clear about your application and requirements. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@j... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Andrew Welch Sent: Wednesday, 2 September 2009 16:46 To: noah_mendelsohn@us.ibm.com Cc: Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@w3.org; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 <noah_mendelsohn@us.ibm.com>: > Hi, Scott.  Further endorsing the advice that Henry and Eliot have > given you, I suggest you might be interested in the TAG's finding that > specifically encourages you to provide useful information that can be > retrieved using the namespace URI.  See [1]. > > Noah > > [1] http://www.w3.org/2001/tag/doc/nsDocuments/ ...but avoid using dates, for example: http://www.w3.org/1999/XSL/Transform http://www.w3.org/2001/XMLSchema would have been much better as: http://www.w3.org/XSLT http://www.w3.org/XMLSchema ....then you don't have to reassure newbies that they really are using modern technologies (2.0 and 1.1), despite what they may think from the namespace. I would say the main thing is to choose a namespace that wont need to change, so don't use dates, versions, "beta", codenames etc. Also the namespace is often its branding, so using product names might be great until marketing change their minds and call the product something else... if the xml is visible to the customer they may ask for the namespace to change too. So as an example, if the company is called "foo" and the product is "foobar", you would probably choose "http://foo.com/foobar", which is most likely going to be ok, but I'm beginning to think that "http://foo.com/ns" is the better choice. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 15:23:16 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post06000.htmWed, 02 Sep 2009 17:22:06 GMT 2009/9/2 Simon Cox <simon.cox@j...>: > In some situations it is good to include dates or version numbers in > namespace names. > For example, if your maintenance/governance arrangement expects new > versions, and particularly if the new versions are not compatible with older > versions. > Geography Markup Language from OGC made the mistake of keeping the same XML > namespace for several incompatible versions of GML, and this has caused > confusion. (The policy has since been fixed). > > Of course, you can choose to give your new version a completely new name and > namespace, but sometimes you want to claim continuity, or at least a common > scope, with an earlier product, but not confuse processors by having > incompatible declarations in the same target namesapce. Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 15:54:35 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post08000.htmWed, 02 Sep 2009 16:53:48 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 C. M. Sperberg-McQueen writes: > The record would not be complete without someone observing > that it also has the disadvantage that if the domain name > registration for [your committee] ever lapses, there is no > guarantee that the new owner will refrain from assigning > a new meaning to http://[your committee]/namespaces/xxx For sure. But be careful using this as an argument in favour of using URNs or some other URI scheme -- If you don't care about dereferencing, it doesn't matter that http://[your committee]/namespaces/xxx doesn't dereference today, and might dereference misleadingly in some relatively unlikely future. If you _do_ care, then the mechanisms put in place to support dereferencing of e.g. URNs will almost certainly be vulnerable to the same human-originating failure modes. > The TAG is presumably aware of this problem (having had it > pointed out to them more than once), and has presumably > decided that it does not matter enough to make a difference. > 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. Correct. I am unaware of _any_ examples of published standards-related URIs transitioning from useful to misleading (as opposed to useless). It's not impossible for this to happen, but pretty unlikely. I have a long-standing interest in coming up with some kind of domain-name insurance for web/internet standards . . . > In the short run, that doesn't matter. Whether it matters > in the long run depends on how long you want things to > work, and how dependent you want to be on netscape.com, > for example, continuing to denote what it once denoted. Jonathan Rees has argued, convincingly for me, that e.g. http://www.w3.org/1999/xhtml will always _denote_ the XHTML namespace, by use and precedent, _regardless_ of whether or not the w3.org website persists, or indeed even if w3.org gets reassigned to someone who starts serving pornographicly embellished caricatures of the XHTML spec. editors from that URI. . . I don't expect everyone to be convinced on _that_ point, but what _is_ true I think is that "thinks [will] work" wrt e.g. that namespace URI regardless of who owns the domain or what they put at it, because software, unlike human beings, does _not_ depend on successful retrieval from namespace URIs for proper functioning. Which brings us to Eliot's point: indeed the reason for the bit about dereferencability he quoted is that you _can't_ depend on retrieval, because namespace owners are _not_ required to support it. 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) iD8DBQFKnpHzkjnJixAXWBoRApUkAJ4vG8p93NLkk1SUQulx09y2QQFh3gCfSfuo 2qr8GNAr5ony8g47zs0CyhU= =vaad -----END PGP SIGNATURE----- Received on Wednesday, 2 September 2009 15:41:28 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post07000.htmWed, 02 Sep 2009 16:40:35 GMT 2009/9/2 <noah_mendelsohn@us.ibm.com>: > Hi, Scott.  Further endorsing the advice that Henry and Eliot have given > you, I suggest you might be interested in the TAG's finding that > specifically encourages you to provide useful information that can be > retrieved using the namespace URI.  See [1]. > > Noah > > [1] http://www.w3.org/2001/tag/doc/nsDocuments/ ...but avoid using dates, for example: http://www.w3.org/1999/XSL/Transform http://www.w3.org/2001/XMLSchema would have been much better as: http://www.w3.org/XSLT http://www.w3.org/XMLSchema ....then you don't have to reassure newbies that they really are using modern technologies (2.0 and 1.1), despite what they may think from the namespace. I would say the main thing is to choose a namespace that wont need to change, so don't use dates, versions, "beta", codenames etc. Also the namespace is often its branding, so using product names might be great until marketing change their minds and call the product something else... if the xml is visible to the customer they may ask for the namespace to change too. So as an example, if the company is called "foo" and the product is "foobar", you would probably choose "http://foo.com/foobar", which is most likely going to be ok, but I'm beginning to think that "http://foo.com/ns" is the better choice. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ Received on Wednesday, 2 September 2009 14:47:06 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post04000.htmWed, 02 Sep 2009 15:46:25 GMT On 2 Sep 2009, at 09:40 , Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > C. M. Sperberg-McQueen writes: > >> The record would not be complete without someone observing >> that it also has the disadvantage that if the domain name >> registration for [your committee] ever lapses, there is no >> guarantee that the new owner will refrain from assigning >> a new meaning to http://[your committee]/namespaces/xxx > > For sure. > > But be careful using this as an argument in favour of using URNs or > some other URI scheme -- If you don't care about dereferencing, it > doesn't matter that http://[your committee]/namespaces/xxx doesn't > dereference today, and might dereference misleadingly in some > relatively unlikely future. If you _do_ care, then the mechanisms put > in place to support dereferencing of e.g. URNs will almost certainly > be vulnerable to the same human-originating failure modes. The meaning of some identifiers is given in a way that guarantees permanence of the meaning assigned. If URLs mean things by virtue of the actions and/or intentions of their owners (which is what I understand the TAG's story to be), then when the owner changes, the meaning is necessarily subject to change. The difference at issue is not whether, when you dereference something, you get something 'misleading' or not. The issue is whether the prescribed methods for determinining the denotation of an identifier guarantee stability of denotation over time or not. On the account offered in your email, the system of using URLs as long-lived identifiers seems to depend on (a) the proposition that a URL has a given meaning just when the owner of the relevant domain assigns it that meaning, and (b) the proposition that a URL has a given meaning whenever we feel like interpreting that way, regardless of the actions of the owner of the relevant domain. The TAG may have no trouble reconciling those two propositions; I confess that to me, they just look like a contradiction at the heart of the TAG's edifice. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** Received on Wednesday, 2 September 2009 16:53:48 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post00001.htmWed, 02 Sep 2009 10:53:09 GMT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tsao, Scott writes: > Thanks very much for your suggestions! > > Is http: URI that same as URL? Many people use 'URL' to mean 'URI using the http: scheme', yes. > And, is the use of them for namespace names (in lieu of URN) > recommended by standards organizations such as W3C and OASIS? Absolutely. OASIS have backed off using URNs as namespace names, and W3C TAG strongly recommends using http: URIs for this purpose. > The committee (we are participating in) seems to think that we > should register a formal URN namespace for "global" uses like OASIS > and S1000D have done [1], because that would allow us to use this > unique namespace as part of our schema namespace structure for > different schemas in different specifications. Why doesn't the same apply for e.g. http://[your committee]/namespaces/xxx? Which has the additional benefit that as I mentioned before, you can document your namespace at that URI... 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) iD8DBQFKnj1akjnJixAXWBoRAgpnAJ946RWeMWRT4NA3S1hHT0bCc63GPgCcDCJp 3NNY0Glqx4E0BJeWcEZs0z8= =zpxU -----END PGP SIGNATURE----- Received on Wednesday, 2 September 2009 09:40:33 GMT ]]>http://xsd.stylusstudio.com/2009Sep/post01000.htmWed, 02 Sep 2009 10:39:38 GMT Hi, Scott. Further endorsing the advice that Henry and Eliot have given you, I suggest you might be interested in the TAG's finding that specifically encourages you to provide useful information that can be retrieved using the namespace URI. See [1]. Noah [1] http://www.w3.org/2001/tag/doc/nsDocuments/ -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- ekimber <ekimber@reallysi.com> Sent by: xmlschema-dev-request@w3.org 09/02/2009 09:12 AM To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Tsao, Scott" <scott.tsao@boeing.com>