Subject: [MEDIACTRL] msc-ivr.xsd and particle unique attribution constraint in draft-ietf-mediactrl-ivr-control-package-04

From: Jean-Francois Bertrand <[email-masked]>
Date: Tue, 10 Feb 2009 08:09:19 -0800

the following msc-ivr.xsd schema construct causes problem with xerces-c when enabling parser.setValidationSchemaFullChecking( true ) and parser.setValidationConstraintFatal( true ):

 <xsd:complexType name="Tcore">
  <xsd:annotation>
   <xsd:documentation>
    This type is extended by other component types to
    allow elements and attributes from other namespaces
    to be added.
   </xsd:documentation>
  </xsd:annotation>
  <!-- non deterministic? -->
  <xsd:sequence>
   <xsd:any namespace="##other" minOccurs="0"
    maxOccurs="unbounded" processContents="lax" />
  </xsd:sequence>
  <xsd:anyAttribute namespace="##other" processContents="lax" />
 </xsd:complexType>

as every complex type fails with: "complex type '....Type' violates the unique particle attribution rule in its components '##other' and '##other'".  The reason appears to be because the schema does not respect the particle unique attribution constraint.  Is this something that's worth fixing?

thanks

Jean-François Bertrand, ing.
Sr. Software Designer
BroadSoft, Inc.
Montreal, Qc, Canada

---

From: [email-masked]
Date: Tue, 10 Feb 2009 19:24:21 +0100

Hi Jean-Francois,

indeed I think this is a well known issue, which comes out over and  
over again when you have "any" style elements in the schema (which,  
btw, are usually there to allow for future extensions of the data  
models). We have this issue in XCON, too, whose data model extends the  
one in RFC4575 in a "non-lean-and-mean" fashion.

Cheers,

Simon

Quoting Jean-Francois Bertrand <[email-masked]>:

> the following msc-ivr.xsd schema construct causes problem with   
> xerces-c when enabling parser.setValidationSchemaFullChecking( true   
> ) and parser.setValidationConstraintFatal( true ):
>
> as every complex type fails with: "complex type '....Type' violates   
> the unique particle attribution rule in its components '##other' and  
>  '##other'".  The reason appears to be because the schema does not   
> respect the particle unique attribution constraint.  Is this   
> something that's worth fixing?
>
> thanks
>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 13 Feb 2009 19:34:21 +0000

Yes, it is something worth fixing. I checked the schema against the w3c xml schema tester and it failed with  non-deterministic content models. So I've modified the schema so Tcore doesn't define 'any' sequence and put an 'any' sequence into type definitions which didn't already have it. It seems to fix the problem, but I'll do a little more testing first. If ok, I'll add it to the -05 version next week. 

Thanks

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Bertrand
Sent: Tuesday, February 10, 2009 17:09
To: [email-masked]
Subject: [MEDIACTRL] msc-ivr.xsd and particle unique attribution constraint in draft-ietf-mediactrl-ivr-control-package-04

  <xsd:anyAttribute namespace="##other" processContents="lax" />  </xsd:complexType>

thanks