Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Entity workaround for extending an enumerated list via redefine

From: "Michael Kay" <mike@--------.--->
To: "'Hirtle, David'" <David.Hirtle@--------.--.-->, <xmlschema-dev@--.--->
Date: 3/8/2005 11:52:00 PM
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@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Hirtle, David
> Sent: 04 March 2005 17:24
> To: xmlschema-dev@w...
> 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>
> 
> 



From joe@i... Wed Mar 09 09:39:10 2005
Received: from wiggum.w3.org ([128.30.52.23])
	by frink.w3.org with esmtp (Exim 4.44)
	id 1D8xeo-0007GD-BV
	for xmlschema-dev@l...


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent