- From: Michael Kay <mike@saxonica.com>
- Date: Tue, 8 Mar 2005 23:51:33 -0000
- To: "'Hirtle, David'" <David.Hirtle@nrc-cnrc.gc.ca>, <xmlschema-dev@w3.org>
Thinking again about this requirement, I feel the right approach is a kind of "parameterized schema". There are a number of technologies that one could use to implement this, but a very flexible approach would be to define a skeletal schema as an XSLT stylesheet with parameters: <xsl:stylesheet version="2.0" xmlns:xsl="..."> <xsl:param name="innerclose-type" as="xs:string"/> <xsl:param name="import-xyz-location" as="xs:anyURI"/> <xsl:template name="make-schema"> <xs:schema...> <xs:import namespace="xyz" schemaLocation="{$import-xyz-location}"/> <xs:attribute name="innerclose" type="{$innerclose-type}"/> </xs:schema> </xsl:template> </xsl:stylesheet> You can then run this stylesheet (with no source document) with different parameter values to produce any tailored schema that you want. Of course, you still have a significant problem in managing the deployment of these variant schemas, for example if two trading partners are using different variants. But I can imagine ways of resolving that, for example each variant schema that is generated could require a top-level attribute with a fixed value that identifies the variant in use. A set of enumeration values such as currencies could be generated by the stylesheet from a source XML document whose URI is identified by one of the stylesheet parameters. <xsl:for-each select="document($currency-doc)/*/currency"> <xs:enumeration value="{.}"/> </xsl:for-each> This all seems much more flexible than trying to use redefines or XML entities. The downside, though, is that there is no inheritance relationship: you end up with different people using the same names to refer to different things. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of Hirtle, David > Sent: 04 March 2005 17:24 > To: xmlschema-dev@w3.org > Subject: Entity workaround for extending an enumerated list > via redefine > > > I need to define an attribute > > <xs:attribute name="innerclose" use="optional"> > <xs:simpleType> > <xs:restriction base="xs:NMTOKEN"> > <xs:enumeration value="universal"/> > </xs:restriction> > </xs:simpleType> > </xs:attribute> > > and later extend the enumerated type to include > > <xs:enumeration value="existential"/> > > via <redefine>. > > Now, I realize that extending an enumerated list with <redefine> isn't > possible. But digging through the mailing list archives, I see that a > work-around involving entities was mentioned back in 2003 (and later > confirmed by Henry Thompson): > http://lists.w3.org/Archives/Public/xmlschema-dev/2003Jun/0074.html > > My question is this: can this work-around be modified to work > with redefine? > In > http://www.ruleml.org/0.89/xsd/modules/connective_module.xsd, > I added a > general entity declaration (which is initially empty) to the > top of the > schema, > as well as a reference to the entity (called > innerclose-universal) where the > enumeration needs to be extended: > > <!DOCTYPE xs:schema [ > <!ENTITY innerclose-universal ''> > ]> > > ... > > <xs:attribute name="innerclose" use="optional"> > <xs:simpleType> > <xs:restriction base="xs:NMTOKEN"> > <xs:enumeration value="universal"/> > &innerclose-universal; > </xs:restriction> > </xs:simpleType> > </xs:attribute> > > Now in the redefining schema > (http://www.ruleml.org/0.89/xsd/folog.xsd), I > try > to overwrite the value of the empty entity with an additional > enumeration: > > <!DOCTYPE xs:schema [ > <!ENTITY innerclose-universal '<xs:enumeration value="existential"/>'> > ]> > > However, this doesn't seem to work with either Saxon-SA 8.3 or the > current XSV (results > below), e.g. when trying to validate > http://www.ruleml.org/0.89/exa/folog.ruleml. > Is this a matter of not being able to overwrite general > entities? (If so, > there must > be another way to accomplish this.) It doesn't appear as > though the entity > is being > expanded by the XML parser before the validation is taking place. > > Am I missing something? > > Thanks, > > David > > *** > > Saxon: > > Validation error on line 10 column 32 of > http://www.ruleml.org/0.89/exa/folog.ruleml: > Invalid value {existential}. Value "existential" violates the > enumeration > facet > "universal" of the type of attribute innerclose > > XSV: > > <invalid char="2" code="cvc-attribute.1.2" line="10" > resource="http://www.ruleml.org/0.89/exa/folog.ruleml">attribute type > check failed for {None}:innerclose: existential not in enumeration > [universal] > </invalid> > >
Received on Tuesday, 8 March 2005 23:51:43 UTC