-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/20/09 9:52 PM, Mike Cumings wrote:
> Good day all,
> 
> I've found a couple issues with XEP-0124 - specifically in it's schema
> definition.  Perhaps we'd like to fix them for this 1.8 update?
> Here's what I've found:
> 
> First, when I tried to compile the schema I ran into problems with the
> 'type' attribute having both a declared type as well as a type derived
> in the restriction clause.  This can be fixed with the following
> change (line numbers relative to the beginning of the schema
> definition):
> 
> @@ -78,7 +83,7 @@
>        <xs:attribute name='sid' type='xs:string' use='optional'/>
>        <xs:attribute name='stream' type='xs:string' use='optional'/>
>        <xs:attribute name='to' type='xs:string' use='optional'/>
> -      <xs:attribute name='type' type='xs:string' use='optional'>
> +      <xs:attribute name='type' use='optional'>
>          <xs:simpleType>
>            <xs:restriction base='xs:NCName'>
>              <xs:enumeration value='error'/>

It seems that I had already fixed that in my working copy, probably
based on feedback I received recently from Kevin Winters regarding the
schemas in XEP-0124 and XEP-0206.

> After I fixed the above, the schema continued to fail compilation but
> for problems inherited from the streams schema:
> http://www.xmpp.org/schemas/streams.xsd.  I was about to track this
> issue down there as well, but began to wonder why it's inclusion is
> relevant after the XMPP over BOSH spec was pulled out?  

You're right, I don't think we need to import the streams namespace here.

> If XEP-0124
> intends to truly be payload agnostic, letting XEP-0206 define
> XMPP-related application, then perhaps the schema inclusion and all
> the child element definitions can be removed from the XEP-0124 schema
> althogether?  Making this change locally resolved all schema
> compilation issues for me.

Super.

I think that what we need is to remove all of the XMPP-specific bits of
the schema and just have this:

  <xs:element name='body'>
    <xs:complexType>
      <xs:choice>
        <xs:element name='uri'
                minOccurs='0'
                maxOccurs='1'
                type='xs:string'/>
        <xs:any namespace='##other'
                minOccurs='0'
                maxOccurs='unbounded'
                processContents='lax'/>
      </xs:choice>
    ...
  </xs:element>


> Beyond the compilation issues, I encountered two missing attribute 
> definitions:
> 
> @@ -48,6 +48,7 @@
>                  processContents='lax'/>
>        </xs:choice>
>        <xs:attribute name='accept' type='xs:string' use='optional'/>
> +      <xs:attribute name='ack' type='xs:positiveInteger' use='optional'/>
>        <xs:attribute name='authid' type='xs:string' use='optional'/>
>        <xs:attribute name='charsets' type='xs:NMTOKENS' use='optional'/>
>        <xs:attribute name='condition' use='optional'>
> 
> and:
> 
> @@ -86,6 +87,7 @@
>            </xs:restriction>
>          </xs:simpleType>
>        </xs:attribute>
> +      <xs:attribute name='ver' type='xs:string' use='optional'/>
>        <xs:attribute name='wait' type='xs:short' use='optional'/>
>        <xs:attribute ref='xml:lang' use='optional'/>
>        <xs:anyAttribute namespace='##other' processContents='lax'/>

Fixed.

> I've not done a complete review of the entire schema's contents.  I'm
> only reporting the problems I've encountered thus far.  

I'll check it over today.

> While these
> issues don't address core spec functionality, having a correct schema
> does assist development and testing.

Agreed.

> Hope this helps.  Thanks for the effort involved in defining and
> maintaining this spec!  Enjoy,

No, thank you!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknt6ToACgkQNL8k5A2w/vxsrACgvCh8fr7OyGiaewTIWx6X2Pfs
OFsAnjV2ZDZQp9dI6b8xD1gFWoTOckwQ
=oZgx
-----END PGP SIGNATURE-----

Reply via email to