RE: phantom attribute?

I might be misunderstanding what you're saying, but it seems that you're
assuming that I can rename the elements.  I can't.  I'm trying to build a
schema around an existing convention.  I'm not free to change any of the
element or attribute names.

Here are some points to consider:
1.  'method' elements may contain 'arg' elements
2.  'signal' elements may contain 'arg' elements.
3.  When an 'arg' element appears with 'method', the 'arg' element must
include a 'direction' attribute (default = "in")
4.  When an 'arg' element appears with 'signal', the 'arg' element must NOT
include a 'direction' attribute.

Thanks for your input.

David

-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Cheney, Edward A SSG RES USAR
Sent: Thursday, September 30, 2010 9:19 AM
To: David McBride
Cc: xmlschema-dev@w3.org
Subject: Re: phantom attribute?

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 17:51:37 UTC