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-a... 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" sendtime="2007-11-09T05:15:05"> <software name="TapirDotNET" version="0.1 (revision )"/> </source> <destination>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.
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-a... <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-a... 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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
Hi Dave, Thanks. I don't think we wanted to be strict in these cases (as far as I can remember). I'll take the liberty to change the schema in all those places, also considering Markus' suggestion. If anyone else has a better idea, please let me know after the notifications. Best Regards, -- Renato On 9 Nov 2007 at 9:54, Dave Vieglais wrote:
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
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" sendtime="2007-11-09T05:15:05"> <software name="TapirDotNET" version="0.1 (revision )"/> </source> <destination> 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:complexT yp e[1]/xsd:choice[1]/xsd:any[1] /xsd:schema/xsd:complexType[34]/xsd:sequence[1]
regards, Dave V.
participants (3)
-
Dave Vieglais -
Döring, Markus -
Renato De Giovanni