Re: [business-transaction] Possible schema errata comments on BTP 1.1

[Doug Bunting <Doug.Bunting@Sun.COM>]

Tony,

After a bit of pedantic re-reading of the Schema specification...

On 21-Jan-05 09:05, Tony Fletcher wrote:
> Dear Colleagues, 
>  
> Three potential schema errata issues:

...

>  B)  The BTP core schema in its definition of the element qualifier has 
> both complexType and complexContent marked as mixed:
> <complexType name="qualifier-type" mixed="true">
>   <complexContent mixed="true">
>  
> Is it necessary to mark both, would not just marking the complexType be 
> sufficient?

Having both is not necessary but it is also not a problem.  The attribute 
on the complexType provides a default for the contained complexContent.  I 
do not see a reason to change anything here.

> This seems to mean that in the qualifiers schema each element defined as 
> being in the substitution group btp:qualifier should have (at least) its 
> complexType marked as mixed.   For instance:
> <element name="transaction-timelimit" substitutionGroup="btp:qualifier"> 
>   <complexType mixed="true">
>  
> and similarly for the other qualifiers.   

This addition is likely necessary because the {content type} of the 
complexType in the various qualifiers is (according to the rules in Section 
3.4.2 of XML Schema part 1) not normally inherited and the "mixed" option 
is determined by the information directly provided in the extension.

>  C)  With the above change XMLSpy 2005 (Home Edition) validates all 
> three of the BTP schemas.  However, I have found that the BTP core 
> schema  
> http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-core-schema-wd-05.xsd";  
> and the qualifiers schema do not seem to validate in an alternate XML 
> tool - Oxygen.  In the qualifiers element, I get a  "Schema Component 
> Constraint: Unique Particle Attribution" error against the 'any' element 
> in the choice (refer to http://www.w3.org/TR/xmlschema-1/#cos-nonambig).

...

> seems to keep Oxygen &  XMLspy 2005 happy for the core schema itself as 
> this does not import any other schema.  Unfortunately validation still 
> fails for the qualifiers and node_state_information schema as these 
> import the core schema and mean that we have two or more namespaces for 
> BTP and so we are back in trouble.  ( T he problem being that the XML 
> validator will not always be able to tell whether an element tag in an 
> instance document claimed to be valid against this schema corresponds to 
> the qualifier element or the any element.  The 'partial' fix worked for 
> the core schema because qualifier is in the btp namespace and the 
> ##other forces a replacement for the any to be in a different namespace 
> and so the two are distinct - anything put there in the btp namespace 
> must follow the qualifier fragment of the schema.) 

You have uncovered one of at least two violations of the Unique Particle 
Attribution constraint in XML Schema (section 3.8.6).  Any element content 
of the various concrete qualifiers (the additions to qualifier-type found 
in transaction-timelimit for example) could either be attributed to the 
base type's <any /> or the extensions' complexType.  All of the extension 
content is in a different namespace from the base type (qualifier-type). 
Therefore, this ambiguity occurs whether or not the <any /> in the base 
type includes a 'namespace="##other"' attribute.

A bit more directly, the lack of the ##other attribute makes validation of 
any instance of the transaction-timelimit (and friends) element on its own 
impossible.  Were this possible, the transaction-timelimit element could 
still not appear in a qualifiers element.  Your use of ##other above 
corrects neither problem but makes the second one a bit harder to see 
because it is now spread between two schemas.

> Potential solutions: 
>  
>  1)  One potential solution I can think of is to make all three BTP 
> schemas share the same namespace, use Include rather than Import to 
> bring one into the other then specifying that the any must be in some 
> other name space should solve the problem completely (not tried that yet 
> though I could if people whish to explore that path further as a 
> solution.and so I suggest this change.  It just means that one must use 
> a different namespace for filing this any - if you need to add something 
> in the BTP  then you can still do that by wrapping it up in the 
> qualifier construct.

This would have to be combined with adding ##other to both the 
qualifier-type and qualifiers definitions.

>  2)   An approach that seems to work for all three of the BTP schemas is 
> to  remove the any from the qualifier type (not required for extending 
> this type) and add a divider to qualifiers so that the definition of 
> qualifiers and qualifier is as follows:

...

This change would have the side effect of making the concrete qualifiers no 
longer extensible.  That is, transaction-timelimit and the other qualifiers 
may appear in a BTP message with additional content at the beginning.  More 
realistically, none of these concrete qualifiers may ever appear in a BTP 
message and validate but I am assuming it was our intention to make 
transaction-timelimit and its ilk be extensible.  Right?

2a) Would add an empty "qualifier-divider" element to the end of the base 
qualifier-type.  This would preserve extensibility of the types in that 
substitution group (the concrete dividers).  In that case, because the <any 
/> appears at the start of the element and is presently unconstrained 
(meaning the qualifier-divider might match the <any />, we would need 
##other in the base qualifier-type's <any />.

>  3)  Could go further and change the qualifiers definition so that the 
> "must-be-understood" and "to-be-propagated" attributes are applied to 
> the any extension as well - something like:

...

I am not sure what this has to do with the Unique Particle Attribution 
constraint but it may be worthwhile.  Does anything in the specification 
imply a need for this?

>  4) Define the content of qualifiers to be 'any'. This fixes the 
> immediate problem. Leaves the problem that custom qualifiers are not 
> required (according to the schema only, not the spec text) to have the 
> two qualifier attributes (and neither does the current schema.)

I am not sure about the problem you say is left.  The concrete qualifiers 
all inherit their base content from the qualifier-type and extend it.  They 
therefore have the two optional attributes in their content model.

If you are using "custom qualifiers" to talk about concrete qualifiers 
beyond those in our qualifiers schema, the "easiest" way to distinguish a 
qualifier from other content in the qualifiers element is based on type 
derivation or substitution group membership.  Neither is particularly 
simple and changing the qualifier-type to make one or both attributes 
required might improve the situation.

On the other hand, I do not remember why the qualifiers element is 
extensible in the first place.  If it must contain elements other than 
those in the qualifier substitution group, how simple must it be to 
distinguish qualifiers from non-qualifiers?

Finally, this solution does not cover the attribution problem for the 
concrete qualifiers (again, transaction-timelimit and friends).

>  5) Define a 'qualifier' element with our two attributes, and 'any' 
> content. Then define 'qualifiers' as an unbounded sequence of 
> 'qualifier' elements. Both problems solved.

What two problems are you covering?  The base qualifier element already has 
'any' content and two optional attributes.  This solution gets rid of the 
(potentially unnecessary) extensibility of the qualifiers element but 
leaves the attribution problem for the concrete qualifiers open.

6) One other option for the ambiguity found in the qualifier substitution 
group would derive their types by restriction rather than extension.  That is:

     <element name="transaction-timelimit" substitutionGroup="btp:qualifier">
         <complexType>
             <complexContent mixed=true>
                 <restriction base="btp:qualifier-type">
                     <sequence>
                         <element name="timelimit" type="nonNegativeInteger"/>
                         <any processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
                     </sequence>
                 </extension>
             </complexContent>
         </complexType>
     </element>

This moves the extension point for the transaction-timelimit element to its 
end.  We could alternatively leave that extension point at the start and 
qualify it with ##other.

This setup relies upon the fact that attributes are inherited from the base 
type even in a restriction unless explicitly prohibited.

...

> Best Regards,
> 
> Tony

...

thanx,
	doug