RE: phantom attribute?

I suddenly realized why I'm seeing the "phantom attribute"  It doesn't solve
the problem, but at least I think I understand the behavior a little better.

I believe that the java-based parser is applying the default value for the
'direction' attribute to ALL instances of 'arg', regardless of whether they
belong to a 'signal' or 'method' element. THEN, it is performing the
validation, at which point it sees a bunch of 'signal' element nodes with
'arg's with direction attributes, and throws exceptions.  So, the parser is
using one definition of 'arg' to apply the default value of 'direction',
then using the other definition of 'arg' to invalidate the use of the
direction attribute!  Talk about confusion!

So, my theory is that the perl parser is doing the opposite:  It is
conducting the validation, THEN applying the default values.  That's why I
saw the problem with the java parser, but not the perl parser.

Thanks for everyone's 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 Saturday, 2 October 2010 00:34:45 UTC