W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2005

Re: Entity workaround for extending an enumerated list via redefine

From: Dan Vint <dvint@dvint.com>
Date: Fri, 04 Mar 2005 11:39:51 -0800
Message-Id: <6.1.0.6.2.20050304102121.030ae958@mail.dvint.com>
To: "Hirtle, David" <David.Hirtle@nrc-cnrc.gc.ca>,xmlschema-dev@w3.org

I don't think this approach works because you are doing what needs to be 
worked around.  The reason for the entity was to just be able to edit that 
file and add the values you need to it right there because redefine doesn't 
allow you to do it.

Think of the entity as a variable that gets substituted in where ever 
referenced- so the use of the entity becomes just the same as if you had 
typed that information in anyway.

The reason the entity process works, when you edit the file contents, is 
that the entity reference gets substituted in line before parsing the first 
time. Essentially it is just like editing the original schema to add the 
enumerations that you want to add. The only advantage to this approach is 
that you can reuses these files with the next version of the schema rather 
than having to re-edit all the lists that you modify.

BTW we have taken a slightly different approach to this problem. Because I 
control the generation of the original schema we are doing the following:

1) Produce a base schema that references a type for each list with no 
enumerations.
2) Produce a second schema that redefines those list types to the 
enumerated values.

Anyone needing to modify those lists modifies the second redefining schema. 
Now when I release the next version, all that has to happen is the modifier 
reviews the new redefining schema for new lists. These changes have to be 
copied into the file they originally modified. They also have to find any 
changes to the existing lists as well.

They then use the newly produced base schema and point their modified 
redefine schema to point at the this file instead of the original base schema.

This has the advantage of creating one single file with all the 
modifications. It still is not a perfect solution, but it is the best 
compromise that we could come up with.

We also made the type of the lists to be QNAME and we require that anyone 
adding a value to a list use an appropriate namespace prefix to identify 
their additions.


Hope this helps
..dan

At 09:23 AM 3/4/2005, Hirtle, David wrote:

>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>

---------------------------------------------------------------------------
Danny Vint

Specializing in Panoramic Images of California and the West
http://www.dvint.com

voice: 510-522-4703


     
Received on Friday, 4 March 2005 19:36:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:49 GMT