← Prev in month ← Prev in thread
Next in thread → Next in month →

Possible schema errata comments on BTP 1.1

From
Tony Fletcher <>
Date
2005-01-21T17:05:37+00:00
ID
003e01c4ffdb$6ac4a750$
Thread
Possible schema errata comments on BTP 1.1
Title: Message

Dear Colleagues, 

 

Three potential schema errata 
issues: 

 

 A)  Peter et al know about this, but 
just to log the issue formally - the namespace URLs used in each of the three 
BTP schema need to be updated to reflect CD status (rather than WD-04 or 
WD-05).

 

 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?

 

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.   

 

 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).

 

Now this may be no great problem in practice in this 
case  but it does seem 
a bit bad to specify a schema that does not validate, and it can be annoying and 
possibly might hid more serious errors if one was trying to extend 
properly.

 

The currently this part 
of the schema is:

<element 
name="qualifiers">
        
<complexType>
            
<choice>
                
<element ref="btp:qualifier" minOccurs="0" 
maxOccurs="unbounded"/>
                
<any processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
            
</choice>
        
</complexType>
    
</element>

 

Changing it 
to:

<element 
name="qualifiers">
        
<complexType>
            
<choice>
                
<element ref="btp:qualifier" minOccurs="0" 
maxOccurs="unbounded"/>
                
<any  namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
            
</choice>
        
</complexType>
    
</element>

 

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.) 

 

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.

 

 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:

<complexType name="qualifier-type" 
mixed="true">
        
<complexContent 
mixed="true">
            
<restriction 
base="anyType">
                
<attribute name="must-be-understood" type="boolean" use="optional" 
default="true"/>
                
<attribute name="to-be-propagated" type="boolean" use="optional" 
default="false"/>
            
</restriction>
        
</complexContent>
    
</complexType>

    <element name="qualifier" 
type="btp:qualifier-type" abstract="true"/>

 

   
<element 
name="qualifiers">
        
<complexType>
            
<sequence>
                
<element ref="btp:qualifier" minOccurs="0" 
maxOccurs="unbounded"/>
                
<element 
name="qualifiers-divider">
                    
<complexType/>
                
</element>
                
<any processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
            
</sequence>
        
</complexType>
    
</element>
    

The "qualifiers-divider" element is always empty (so 
never has any content that needs to go to / from the BTP engine / application) 
and just acts as a mechanism to 'synchronise' an XML validator so that it knows 
whether it is dealing a qualifier or something replacing the any element.  
The other two schema are left unchanged, and still seem to validate fine 
now.

 

 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:

<element 
name="qualifiers">
        
<complexType>
            
<sequence>
                
<element ref="btp:qualifier" minOccurs="0" 
maxOccurs="unbounded"/>
                
<element 
name="qualifiers-divider">
                    
<complexType/>
                
</element>
                
<element 
name="addition">
                    
<complexType 
mixed="true">
                        
<complexContent 
mixed="true">
                            
<restriction 
base="anyType">
                                
<sequence>
                                    
<any processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
                                
</sequence>
                                
<attribute name="must-be-understood" type="boolean" use="optional" 
default="true"/>
                                
<attribute name="to-be-propagated" type="boolean" 
use="optional"     
default="false"/>
                            
</restriction>
                        
</complexContent>
                    
</complexType>
                
</element>
            
</sequence>
        
</complexType>
    
</element>

 

 

 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.)

 

 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.

 

Out of all five possible solutions presented thus far, only 
(4) is backwards compatible with BTP 1.0.

 

 

 

Best 
Regards,

Tony                           

  
  

    
      

    
      
Tony 
      Fletcher

      
Technical 
      Advisor 
      
Choreology 
      Ltd.
68, Lombard Street, London EC3V 9L J  
       UK

  

    
      
Phone:  
      

    
      
+44 
      (0) 1473 729537

  

    
      
Mobile: 
      

    
      
+44 
      (0) 7801 948219

  

    
      
Fax:    
      

    
      
+44 
      (0) 870 7390077

  

    
      
Web:

    
      
www.choreology.com

  

    
      
Cohesions™

  

    
      
Business 
      transaction management software for application 
      coordination

  

    
      

      

Work:  
      

  

    
      
Home: 
      
← Prev in month ← Prev in thread
Next in thread → Next in month →