xml-dev - RE: XML Schemas: ref'ing vs inlining

[Curt Arnold <CurtA@techie.com>]

Here are a couple of other sections that touch on duplicates (now that I
know the key is to search for "two or more"):

Section 2.5 (Names and symbol spaces)

Locally scoped attribute and element declarations are special with
regard to symbol spaces. Every complex type definition defines its own
local attribute and element declaration symbol spaces, where these
symbol spaces are distinct from each other and from any of the other
symbol spaces. So, for example, two complex type definitions having the
same target namespace can contain a local attribute declaration for the
unqualified name "priority", or contain a local element declaration for
the name "address", without conflict or necessary relation between the
two.

Section 3.7 (model group details):

When two or more element declarations with the same identity occur at
any level within a model group, their type definitions must be the same.

Section 5.7 (model groups constraints): 

If the {particles} contains, either directly, indirectly (that is,
within the {particles} of a contained model group, recursively) or
implicitly two or more element declaration particles with the same
{name} and {target namespace}, all their {type definition}s must be the
same.

Section 5.13 (schema constraints):

2  Each of the {type definitions}, {element declarations}, {attribute
group definitions}, {model group definitions} and {notation
declarations} must not contain two or more schema components with the
same {name} and {target namespace}.  
-----------------

From 5.13, it would be a violation to have even perfectly identical
element declarations as top-level schema elements.  For example:

<schema targetNamespace="http://www.example.org/"
         xmlns="http://www.w3.org/1999/XMLSchema">
   <element name="bar" type="string"/>
   <element name="bar" type="string"/>
</schema>

should be illegal.

Section 2.5's discussion that a symbol space was associated with the
complex type was the basis of my thinking that:

<schema...>
   <element name="foo">
	<complexType>
	    <element name="bar" type="string"/>
	    <element name="bar" type="string"/>
        </complexType>
   </element>
</schema>

would be illegal.  Basically, since perfectly identical declarations in
the global symbols space were illegal, I inferred (without knowledge of
the other two sections) that perfectly identical declarations in a
complex type's symbol space would be also be illegal.


In a previous message, I said:	
>> They'd at least need to match on any <appinfo> element since that
>> might be used for additional processing.

And Henry replied:
>Why so?  The whole point of Unique Attribution is that you know which
>particle accounts for which bit of the input. 	

Given this example:

<schema...>
   <element name="foo">
	<complexType>
	    <element name="bar" type="string">
		<annotation>
	             <appinfo>
			<validator class="com.example.firstBar"/>
		     </appinfo>
                </annotation>
             </element>
 	    <element name="bar" type="string">
 		<annotation>
 	             <appinfo>
 			<validator class="com.example.secondBar"/>
 		     </appinfo>
                 </annotation>
              </element>
         </complexType>
    </element>
</schema>

An application will depend on the parser or the DOM to allow it to
determine the corresponding element declaration for a particular element
so that it can get to the appinfo.  To return the proper appinfo, the
schema processor will two have two distinct objects for the first and
second element declarations.

However if you can do that, it should be a breeze to handle:

<schema...>
   <element name="foo">
	<complexType>
	    <element name="bar" type="string"/>
 	    <element name="bar" type="long"/>
         </complexType>
    </element>
</schema>

Therefore, the restrictions of sections 3.7 and 5.7 don't simplify the
implementation of schema and the discussion of symbol spaces being tied
to complex types is misleading.  Both these seemed premised on the
concept that there could be only one element declaration of a specific
name within a complex type.

I'd suggest removing the type definitions equivalance constraint from
3.7 and 5.7 and reworking the paragraph in section 2.5.

If you don't remove the type equivalance constraints, then what
constitutes an identical type:

How about:

<schema...>
   <element name="foo">
	<complexType>
	    <element name="bar">
		<simpleType base="long">
		    <minInclusive>0</minInclusive>
		    <maxInclusive>10</maxInclusive>
		</simpleType>
	    </element>
	    <element name="bar">
		<simpleType base="long">
		    <minInclusive>0</minInclusive>
		    <maxInclusive>10</maxInclusive>
		</simpleType>
	    </element>
         </complexType>
    </element>
</schema>

What if the order of facets in one of the types was reversed?  What if
they different only in the annotation?

And the bug question, why didn't Roger just do

<element name="foo">
	<complexType>
		<element name="bar" type="string" maxOccurs="2"/>
	</complexType>
</element)

so we could have avoided this whole issue.