W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2010

Re: phantom attribute?

From: Cheney, Edward A SSG RES USAR <austin.cheney@us.army.mil>
Date: Thu, 30 Sep 2010 11:18:33 -0500
To: David McBride <dmcbride@codeaurora.org>
Cc: xmlschema-dev@w3.org
Message-ID: <f70ab5ff8175.4ca47209@us.army.mil>
David,

Part of the confusion is due to more than one definition of elements/attributes with the same name.  For instance you define an element, arg, more than once.  As a result do you know which of those elements named arg is causing the problem?  I would suspect not, but that you infer the specific element by examining the parent.  Such reasoning is problematic that results in unnecessary complication that grows like a cancer as your schema base becomes more complex itself.

I recommend you declare all attributes and elements once in the global space.  Then use element/attribute references in your structure and type definitions to point to the specifically named element/attribute.

Consider this revision of your schema:

<xs:attribute name="name"/>
<xs:attribute name="type" type="arg_and_property_type" use="required"/>
<xs:attribute default="in" name="direction" type="arg_direction"/>
<xs:element name="annotation"/>
<xs:element name="arg" type="method_arg_type"/>
<xs:element name="arg-signal" type="signal_arg_type"/>

<xs:complexType name="signal_arg_type">
    <xs:sequence>
        <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
    </xs:sequence>
    <xs:attribute ref="name"/>
    <xs:attribute ref="type"/>
</xs:complexType>
<xs:complexType name="method_arg_type">
    <xs:attribute ref="name"/>
    <xs:attribute ref="type"/>
    <xs:attribute ref="direction"/>
</xs:complexType>

<xs:element name="method">
    <xs:complexType>
        <xs:choice maxOccurs="unbounded" minOccurs="0">
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="arg-method"/>
        </xs:choice>
        <xs:attribute ref="name" use="required"/>
    </xs:complexType>
</xs:element>
<xs:element name="signal">
    <xs:complexType>
        <xs:choice maxOccurs="unbounded" minOccurs="0">
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="arg-signal"/>
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
        </xs:choice>
        <xs:attribute ref="name" use="required"/>
    </xs:complexType>
</xs:element>

You will notice in my reformulation of the schema section that I renamed the arg element to arg-method and arg-signal to not only differentiate the elements, as well as their types, but also to include identifiable reference to their respective context.  I can understand how you may have arguments against such a practice, but the reality is that the two arg elements from your schema are not the same element any ways since they have different contexts and different types.  So, naming their differently does nothing to alter the logic respective of the schema instance's tree structure.

The problem in your parser is that it is not strictly accounting for lambda scoping that is inherently resident in XML but is not in inherently resident in Java.  This means that unless there is some programmatic method in place to formulate scope from structure defined context then there is no scope.  If I am correct in my analysis then your schema is valid, but your interpreter has trouble understanding why that is.  If you absolutely need the arg elements to have the same name then make them empty elements and set the type at the point of reference as indicated by this example:

<xs:attribute name="name"/>
<xs:attribute name="type" type="arg_and_property_type" use="required"/>
<xs:attribute default="in" name="direction" type="arg_direction"/>
<xs:element name="annotation"/>
<xs:element name="arg"/>

<xs:complexType name="signal_arg_type">
    <xs:sequence>
        <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
    </xs:sequence>
    <xs:attribute ref="name"/>
    <xs:attribute ref="type"/>
</xs:complexType>
<xs:complexType name="method_arg_type">
    <xs:attribute ref="name"/>
    <xs:attribute ref="type"/>
    <xs:attribute ref="direction"/>
</xs:complexType>

<xs:element name="method">
    <xs:complexType>
        <xs:choice maxOccurs="unbounded" minOccurs="0">
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="arg" type="method_arg_type"/>
        </xs:choice>
        <xs:attribute ref="name" use="required"/>
    </xs:complexType>
</xs:element>
<xs:element name="signal">
    <xs:complexType>
        <xs:choice maxOccurs="unbounded" minOccurs="0">
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="arg" type="signal_arg_type"/>
            <xs:element maxOccurs="unbounded" minOccurs="0" ref="annotation"/>
        </xs:choice>
        <xs:attribute ref="name" use="required"/>
    </xs:complexType>
</xs:element>

This second example is still far weaker than the first example and I suggest your write your code as maturely as possible to avoid parsing issues in the future from incomplete parsers.  If I am in error please let me know and I will see if I can determine an alternate solution.

Thanks,

Austin Cheney, CISSP
http://prettydiff.com/
Received on Thursday, 30 September 2010 16:20:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:18 UTC