- From: Mark Feblowitz <mfeblowitz@frictionless.com>
- Date: Tue, 8 Jan 2002 10:31:54 -0500
- To: "'Ashok Malhotra'" <ashokma@microsoft.com>, Jeni Tennison <jeni@jenitennison.com>
- Cc: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>, "Henry Thompson (E-mail)" <ht@cogsci.ed.ac.uk>
We considered this, and it is a possible fallback for us. By concentrating the changes to a single file, it strikes a pragmatic balance between having a locked-down (inflexible) schema and having a wide-open (user-damageable) schema. The downside of such an approach is that is requires either 1) the schema owner must rapidly field requests and post extensions, or 2) the schema user must copy the schema, in its entirety, insert his own extensions locally, and re-post the extended schema so that interchange partners can benefit from the extension. The former breaks down when the schema owner is not responsive enough. The latter breaks down as more and more parties replicate the schema and make (potentially non-coordinated) changes to it. Option 2 also breaks down as layers are built up (schema C is built on schema B which is built on schema A, all of which do some kind of extension,...). I'm not sure what it means to build this approach into the Schema Rec. - it can be done today, using simpleType definitions and include/import. What would be nifty would be to allow a redefine that would support the extension of the enumeration set, something that I gather would meet significant resistance, since it would remove a key assumption about the completeness/finality of a simpleType definition. Mark ---------------------------------------------------------------------------- ---- Mark Feblowitz [t] 617.715.7231 Frictionless Commerce Incorporated [f] 617.495.0188 XML Architect [e] mfeblowitz@frictionless.com 400 Technology Square, 9th Floor Cambridge, MA 02139 www.frictionless.com -----Original Message----- From: Ashok Malhotra [mailto:ashokma@microsoft.com] Sent: Tuesday, January 08, 2002 9:59 AM To: Mark Feblowitz; Jeni Tennison Cc: Xmlschema-Dev (E-mail); Henry Thompson (E-mail) Subject: RE: simpleType redefinition - must it be a restriction? A better solution is to allow the enumerations to be specified in a separate file which can be updated independent of the Schema. This is a significant change that we can consider for Schema 1.1 or 2.0 All the best, Ashok =========================================================== Ashok Malhotra <mailto: ashokma@microsoft.com> Microsoft Corporation -----Original Message----- From: Mark Feblowitz [mailto:mfeblowitz@frictionless.com] Sent: Monday, January 07, 2002 3:00 PM To: 'Jeni Tennison' Cc: Xmlschema-Dev (E-mail); Henry Thompson (E-mail) Subject: RE: simpleType redefinition - must it be a restriction? > Redefinitions of a simple type must be restrictions of that simple > type (since <simpleType> elements within a <redefine> element must > have a <restriction> child). Restrictions within a redefine follow the > same rules as restrictions elsewhere. That having been stated (and also in ht's message on 11/6/2001, http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0047.html), is there any valid means of achieving the effect of adding enumerations to a simpleType (i.e., extending a simpleType), without altering the original definition? It looks like the simple answer is no, given XML Schema Datatypes Rec, Section 4.3.5.5 Constraints on enumeration Schema Components. Still, the situation often arises where additional enumerated values are needed "between schema releases." The example in my initial query is one such case: the set of currency codes is relatively stable, but new currencies do sometimes emerge (we have many other similar examples, not just currencies). We would like the schema to validate that a currency code is one of the set of valid enumerations, but we also need a way to support transactions that use the new currency code(s). Simply "changing the schema" is not an option in cases where many parties are relying on a stable schema and a predictable release schedule. Ideally, we would like some way to extend the schema to add one or more enumerations to the original simpleType (e.g., by using a redefine). That was the source of my initial example, and looks not to be conformant. Alternately we might want to create a same-named type in another namespace, adding the new enumerated values to the new type. That looks like it won't work, either, and for the same reason: the new type must be a restriction of the base type, which is already more constrained than we'd like (i.e., it disallows the new currencies). It would be possible to create a new simpleType which extends the original set by the use of a union <xs:simpleType name="CurrencyCode"> <xs:restriction base="xs:string"> <xs:enumeration value="USD"/> <xs:enumeration value="EUR"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CurrencyCodeExtended"> <xs:union memberTypes="CurrencyCode CurrencyCodeExtensions"/> </xs:simpleType> <xs:simpleType name="CurrencyCodeExtensions"> <xs:restriction base="xs:string"> <xs:enumeration value="AUD"/> </xs:restriction> </xs:simpleType> Trouble is, this new type can only be used in new definitions (i.e., that refer to the newly created type CurrencyCodeExtended) and not in any of the other contexts where CurrencyCode is already in use. This means that the new currency codes would be valid only in a fraction of the places where currency codes are used. And, unless I'm mistaken, the types/elements that refer to the original type CurrencyCode can't be redefined to use the new CurrencyCodeExtended type, because the latter isn't a restriction of base type CurrencyCode. Another approach, which uses two namespaces, creates a new type ns2:CurrencyCode that is defined as the original CurrencyCode type in ns1 unioned with an expansion set, ns2:CurrencyCodeExtensions: <xs:schema targetNamespace="ns1" xmlns="ns1" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:simpleType name="CurrencyCode"> <xs:restriction base="xs:string"> <xs:enumeration value="USD"/> <xs:enumeration value="EUR"/> </xs:restriction> </xs:simpleType> </xs:schema> <xs:schema targetNamespace="ns2" xmlns:ns1="ns1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="ns2" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="ns1" schemaLocation="unionSimple1.xsd"/> <xs:simpleType name="CurrencyCode"> <xs:union memberTypes="ns1:CurrencyCode CurrencyCodeExtensions"/> </xs:simpleType> <xs:simpleType name="CurrencyCodeExtensions"> <xs:restriction base="xs:string"> <xs:enumeration value="AUD"/> </xs:restriction> </xs:simpleType> </xs:schema> While legal, this suffers from the same problem that the redefine approach suffers from: the new currencies only appear in new definitions that use ns2:CurrencyCode. To resolve this, types that reference ns1:CurrencyCode would have to be copied from ns1 into ns2 and altered to reference ns2:CurrencyCode instead of ns1:CurrencyCode. That, like so many cases of derivation by restriction, causes a replication maintenance nightmare. I have also experimented with some tricks with union types, creating a base type that is the product of unioning a core type plus an unconstrained xs:string extension (as suggested in http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0047.html). Any such approach would require the unioning of a less restrictive set in order to subsequently allow the new enumerations to be viewed as legitimate restrictions. The initial set of enumerations would then only act as documentation and not be usable for validation purposes (a set of strings unioned with the set of all strings is the set of all strings), until one or more new enumerations was added to constrain that other, wide-open set. That trick also breaks down in other cases, e.g, when more that one namespace needs to extend the enumeration. So, my question again is this: is there any way to achieve an extended set of enumerated values, or must I basically throw away enumeration for all but the most stable types? Thanks, Mark ------------------------------------------------------------------------ ---- ---- Mark Feblowitz [t] 617.715.7231 Frictionless Commerce Incorporated [f] 617.495.0188 XML Architect [e] mfeblowitz@frictionless.com 400 Technology Square, 9th Floor Cambridge, MA 02139 www.frictionless.com -----Original Message----- From: Jeni Tennison [mailto:jeni@jenitennison.com] Sent: Saturday, January 05, 2002 8:15 AM To: Mark Feblowitz Cc: Xmlschema-Dev (E-mail); Henry Thompson (E-mail); 'support@xmlspy.com'; 'al@altova.com' Subject: Re: simpleType redefinition - must it be a restriction? Hi Mark, > Must a redefinition of a simpleType result in a more constrained > simpleType? Or can it be less constrained? Redefinitions of a simple type must be restrictions of that simple type (since <simpleType> elements within a <redefine> element must have a <restriction> child). Restrictions within a redefine follow the same rules as restrictions elsewhere. > XMLSpy says that any of AUD, EUR, USD or USD (!) are allowed in the > instance document that references the redefinition xsd. It appears > to have created a union of the original and the redefined > enumeration sets. > > XSV says that only USD and AUD are allowed, treating the redefined > enumeration set as overriding the original. > > I expected the redefinition to be flagged as an error, with the new > definition not being a proper subset of the original. > > What is the correct interpretation? I think your interpretation is the correct interpretation. When you restrict a simple type, the facets have to be valid restrictions of the facets of the base type. In your example the base type had a value space of (USD, EUR); the derived type had an enumeration facet of (USD, AUD). According to the XML Schema Datatypes Rec, Section 4.3.5.5 Constraints on enumeration Schema Components: Schema Component Constraint: enumeration valid restriction It is an *error* if any member of {value} is not in the *value space* of {base type definition}. The restriction is therefore an error because the value 'AUD' is not in the value space of the base type. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Tuesday, 8 January 2002 10:32:26 UTC