- 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