On 2014-12-09 23:45, Dave Kuhlman wrote:
>> Hi,
>>
>> I have an XML schema that declares a complexType (BEHAVIOR-RULES),
>> which
>> includes a reference to an abstract element (BEHAVIOR-RULES) in a
>> xs:sequence. It also declares two other elements (FILE-UPLOAD,
>> RUN-SCRIPT) as subtitutes for this abstract element. And finally
>> another
>> complexType is declared (SYSTEM-BEHAVIOR-RULE), which is derived by
>> extension from BEHAVIOR-RULES.
>>
>> The schema (excerpt) looks like this:
>>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>> elementFormDefault="qualified">
>> <xs:element name="BEHAVIOR-RULES" abstract="true"/>
>> <xs:complexType name="BEHAVIOR-RULES">
>> <xs:sequence>
>> <xs:element ref="BEHAVIOR-RULES"/>
>> </xs:sequence>
>> </xs:complexType>
>> <xs:element name="SYSTEM-BEHAVIOR-RULE">
>> <xs:complexType>
>> <xs:complexContent>
>> <xs:extension base="BEHAVIOR-RULES">
>> <xs:attribute name="_TXN-SUPPORTED_" fixed="DELETE"/>
>> <xs:attribute name="_KEY_" fixed="_CHILD_::_KEY_"/>
>> <xs:attribute name="_CONTAINER_"
>> fixed="SYSTEM-BEHAVIOR-RULE-TABLE"/>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>> </xs:element>
>> <xs:element name="FILE-UPLOAD" substitutionGroup="BEHAVIOR-RULES">
>> <xs:complexType>
>> <xs:attribute name="name" use="required"/>
>> [...]
>> </xs:complexType>
>> </xs:element>
>> <xs:element name="RUN-SCRIPT" substitutionGroup="BEHAVIOR-RULES">
>> <xs:complexType>
>> <xs:attribute name="name" use="required"/>
>> [...]
>> </xs:complexType>
>> </xs:element>
>> </xs:schema>
>>
>> Using this as input, generateDS writes SYSTEM_BEHAVIOR_RULE as a
>> subclass of BEHAVIOR_RULES. However this leads to an error when the
>> constructor of the superclass is called with additional arguments
>> (BEHAVIOR_RULES):
>>
>> [...]
>> File "/tmp/generateds_api.py", line 31480, in factory
>> return SYSTEM_BEHAVIOR_RULE(*args_, **kwargs_)
>> File "/tmp/generateds_api.py", line 31472, in __init__
>> super(SYSTEM_BEHAVIOR_RULE, self).__init__(BEHAVIOR_RULES, )
>> TypeError: __init__() takes exactly 1 argument (2 given)
>
> Zenon,
>
> I made this change to the schema:
>
> --- test01.xsd 2014-12-09 10:07:31.962279242 -0800
> +++ test02.xsd 2014-12-09 10:31:02.954234901 -0800
> @@ -1,7 +1,7 @@
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> elementFormDefault="qualified">
>
> - <xs:element name="BEHAVIOR-RULES" abstract="true"/>
> + <xs:element name="BEHAVIOR-RULES" type="BEHAVIOR-RULES"
> abstract="true"/>
> <xs:complexType name="BEHAVIOR-RULES">
> <xs:sequence>
> <xs:element ref="BEHAVIOR-RULES"/>
>
> That change seems to have eliminated the above error.
Hi Dave,
If I apply this change to the original schema, xmllint throws the
following errors:
element element: Schemas parser error : element decl. 'FILE-UPLOAD': The
type definition '(NULL)' was either rejected by the substitution group
affiliation 'BEHAVIOR-RULES', or not validly derived from its type
definition 'BEHAVIOR-RULES'.
element element: Schemas parser error : element decl. 'RUN-SCRIPT': The
type definition '(NULL)' was either rejected by the substitution group
affiliation 'BEHAVIOR-RULES', or not validly derived from its type
definition 'BEHAVIOR-RULES'.
In addition, adding the type attribute to the substitute elements throws
this error:
element complexType: Schemas parser error : Element
'{http://www.w3.org/2001/XMLSchema}element': The attribute 'type' and
the <complexType> child are mutually exclusive.
>
> I am not aware that we are supposed to be able to infer that an
> element that does not specify a type should default to a type whose
> name is the same as the name of the element. Do you believe that is
> true?
Considering the original schema (quoted at the top), I don't think that
is the case; the element and the complexType are not implicitly linked,
but rather the complexType includes a reference to the element within an
xs:sequence.
>
> # Or, to put it another way, SYSTEM-BEHAVIOR-RULES extends the
> # complexType BEHAVIOR-RULES, but generateDS.py mistakenly looks up
> # the element BEHAVIOR-RULES and extends that.
>
> Or, to view it another way, generateDS.py generates a class for the
> element BEHAVIOR-RULES, whereas it should really generate a class
> based on the *complexType* BEHAVIOR-RULES.
>
> Does this change solve part of the problem for you?
I don't think it does, but let's consider derivation by extension
without abstract elements and substitution groups:
<xs:element name="TIMEZONE">
<xs:complexType>
<xs:complexContent>
<xs:extension base="SUMMERTIME">
<xs:attribute name="_TXN-SUPPORTED_" fixed="SET"/>
[...]
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="SUMMERTIME">
<xs:sequence>
<xs:element ref="SUMMERTIME"/>
</xs:sequence>
</xs:complexType>
<xs:element name="SUMMERTIME">
<xs:complexType>
<xs:sequence>
<xs:element ref="SUMMER-START"/>
<xs:element ref="SUMMER-END"/>
</xs:sequence>
<xs:attribute name="_TXN-SUPPORTED_" fixed="SET"/>
[...]
</xs:complexType>
</xs:element>
<xs:element name="SUMMER-START">
<xs:complexType>
<xs:attribute name="_TXN-SUPPORTED_" fixed="SET"/>
[...]
</xs:complexType>
</xs:element>
<xs:element name="SUMMER-END">
<xs:complexType>
<xs:attribute name="_TXN-SUPPORTED_" fixed="SET"/>
[...]
</xs:complexType>
</xs:element>
It leads to a similar error:
File "/tmp/generateds_api.py", line 94106, in factory
return TIMEZONE(*args_, **kwargs_)
File "/tmp/generateds_api.py", line 94095, in __init__
super(TIMEZONE, self).__init__(summername, _CONTAINER_, _KEY_,
_TXN_SUPPORTED_, SUMMER_START, SUMMER_END, )
TypeError: __init__() takes at most 2 arguments (7 given)
TIMEZONE extends SUMMERTIME and calls its' constructor with the wrong
arguments, which include the members of the SUMMERTIME element above,
but these are not declared in the complexType by the same name. That
does look close to what you noted above.
If I merge xs:complexType[@name="SUMMERTIME"] into
xs:element[@name="TIMEZONE"]/xs:complexType so as to avoid derivation by
extension, as suggested in my previous message, SUMMERTIME is only a
member of TIMEZONE (rather than a super-class) and the problem goes
away.
Thanks for looking into this.
Regards,
Z.
> I have not yet looked into the further complication that you mention
> below. I'll take a look tomorrow.
>
> Dave
>
>
>>
>> I have seen this problem whenever xs:extension is used in such a way.
>> I
>> can work around it if I slightly change the schema so as to avoid
>> deriving by extension, which means removing the BEHAVIOR-RULES
>> complexType and rewriting SYSTEM-BEHAVIOR-RULE like this:
>>
>> <xs:element name="SYSTEM-BEHAVIOR-RULE">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element ref="BEHAVIOR-RULES"/>
>> </xs:sequence>
>> <xs:attribute name="_TXN-SUPPORTED_" fixed="DELETE"/>
>> <xs:attribute name="_KEY_" fixed="_CHILD_::_KEY_"/>
>> <xs:attribute name="_CONTAINER_"
>> fixed="SYSTEM-BEHAVIOR-RULE-TABLE"/>
>> </xs:complexType>
>> </xs:element>
>>
>> However there is a further complication in this case, due to the
>> abstract element. The generated code does not seem to somehow link the
>> abstract element with its' substitutes, so when such nodes are present
>> in the (parsed) input, they are not preserved in the (exported)
>> output,
>> and of course this breaks validation.
>>
>> <SYSTEM-BEHAVIOR-RULE-TABLE>
>> - <SYSTEM-BEHAVIOR-RULE>
>> - <FILE-UPLOAD name="..." [...]/>
>> - </SYSTEM-BEHAVIOR-RULE>
>> + <SYSTEM-BEHAVIOR-RULE/>
>> </SYSTEM-BEHAVIOR-RULE-TABLE>
>>
>> I can overcome the problem if I replace the xs:sequence in the above
>> with an xs:choice containing references to the elements that provide
>> substitutes for BEHAVIOR-RULES.
>>
>> My question is however if generateDS should be able to handle the
>> original schema or not. Having read about element extensions and
>> substitution groups in the documentation, I would tend to say yes, but
>> I
>> am not sure.
>>
>> For the record, this schema is produced by trang
>> (http://www.thaiopensource.com/relaxng/trang.html), which converts
>> from
>> the following DTD (excerpt):
>>
>> <!ENTITY % BEHAVIOR-RULES "(FILE-UPLOAD|RUN-SCRIPT)">
>>
>> <!ELEMENT SYSTEM-BEHAVIOR-RULE (%BEHAVIOR-RULES;)>
>> <!ATTLIST SYSTEM-BEHAVIOR-RULE
>> _TXN-SUPPORTED_ (DELETE|SET|GET) #FIXED "DELETE"
>> _KEY_ CDATA #FIXED "_CHILD_::_KEY_"
>> _CONTAINER_ CDATA #FIXED "SYSTEM-BEHAVIOR-RULE-TABLE"
>> >
>>
>> <!ELEMENT FILE-UPLOAD EMPTY>
>> <!ATTLIST FILE-UPLOAD
>> name CDATA #REQUIRED
>> [...]
>> >
>> <!ELEMENT RUN-SCRIPT EMPTY>
>> <!ATTLIST RUN-SCRIPT
>> name CDATA #REQUIRED
>> [...]
>> >
>>
>> Thanks for your insight.
>>
>> Regards,
>> Zenon Mousmoulas
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
