[tdwg-tapir] xsd:any element processing

[D ö ring, Markus]

I agree with you Dave. Seems we have been too lax when writing the schema.
Would you mind adding yet another attribute, namely namespace=²##other²?
I would prefer to have custom extensions in their own namespaces so
different applications don¹t collide. TapirLinka and PyWrapper do this
already as far as I remember for the skin attribute.

Markus




"Dave Vieglais" wrote on 09.11.2007 18:54 Uhr:

> Hi,
> In http://rs.tdwg.org/tapir/1.0/schema/tapir.xsd, the definition of the
> <custom> element is such that any elements may be included, however the
> <xsd:any> element definition does not include a "processContents" attribute,
> in which case a validator will use the default of "strict" which requires that
> a definition of the contents are available and valid ( i.e. an appropriate
> schema is available to validate the element content).  The relevant XML schema
> reference is: 
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any
> <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-an
> y> 
> 
> I'm curious if that was the intent of the TAPIR design?  If not, then
> including an attribute in <xsd:any> of processContents="lax" (validate if
> possible but ignore problems) or processContents="skip" (don't validate) would
> enable quick evaluation of TAPIR response documents using xml schema
> validation tools without requiring that providers explicitly include a schema
> defining the content of the <custom> element (which seems overly restrictive).
> An appropriate change could be:
> 
>   <xsd:element name="custom">
>     <xsd:annotation>
>       <xsd:documentation>Extension slot for additional information not defined
> in the schema.</xsd:documentation>
>     </xsd:annotation>
>     <xsd:complexType>
>       <xsd:sequence>
>         <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax" >
>           <xsd:annotation>
>             <xsd:documentation>For any custom extension. E.g what security
> related
>             capabilities does the provider have? Encryption, access
> restriction,
>             etc.</xsd:documentation>
>           </xsd:annotation>
>         </xsd:any>
>       </xsd:sequence>
>     </xsd:complexType>
>   </xsd:element>
> 
> I do not believe this will change any functionality of TAPIR providers, but it
> will enable validation of responses such as:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <response xmlns="http://rs.tdwg.org/tapir/1.0"
>                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>                  
> xsi:schemaLocation="http://rs.tdwg.org/tapir/1.0/schema/tapir.xsd">
>   <header>
>     <source accesspoint="
> http://lsid.herbimi.info/TapirDotNET/tapir.aspx/herbIMI
> <http://lsid.herbimi.info/TapirDotNET/tapir.aspx/herbIMI> "
>                    sendtime="2007-11-09T05:15:05">
>       <software name="TapirDotNET" version="0.1 (revision )"/>
>     </source>
>     <destination> 128.111.242.127 <http://128.111.242.127> </destination>
>     <custom><skin>default</skin></custom>
>   </header>
>   <pong/>
> </response>
> 
> which does not validate according to the current TAPIR schema.
> 
> Other places in the schema that may be a problem (because processContents is
> not explicitly stated) are:
> 
> /xsd:schema/xsd:group[1]/xsd:sequence[1]/xsd:element[1]/xsd:complexType[1]/xsd
> :choice[1]/xsd:any[1]
> /xsd:schema/xsd:complexType[34]/xsd:sequence[1]
> 
> 
> regards,
>   Dave V.
> 
> 
> 
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir