1 / 20

SchemaPath: a minimal extension to XML Schema for conditional constraints

SchemaPath: a minimal extension to XML Schema for conditional constraints. Paolo Marinelli Claudio Sacerdoti Coen Fabio Vitali University of Bologna (Italy). Validation. Validation is writing correctness rules for an XML document, and verifying that they hold for every document received.

Download Presentation

SchemaPath: a minimal extension to XML Schema for conditional constraints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SchemaPath: a minimal extension to XML Schema for conditional constraints Paolo Marinelli Claudio Sacerdoti Coen Fabio Vitali University of Bologna (Italy)

  2. Validation • Validation is writing correctness rules for an XML document, and verifying that they hold for every document received. • Possible with a number of schema languages, roughly divided in two kinds: • grammar-based languages: DTD, XML Schema (XSD), Relax NG, etc. A whole generative grammar is created, and every document that can be built with this grammar is valid. • Rule-based languages: Schematron, xlinkit, etc. Rules are defined to check for special conditions (required or rejected). Every document that does not violate any of these rules is valid. Next: Why validate XML documents? 2/20

  3. DOM Tree + PSVI XMLdoc rules rules DOM tree downstream application DOM parser Not well-formed Schema validator Invalid Why validate XML documents? • Usually, when receiving data from an unreliable source, programmers intersperse their application code with checks on data values, error handling, remedial procedures, etc. • Validation does all checks before submitting the data to the downstream application, removing the need for most of the checks on data values. Next: The PSVI 3/20

  4. The PSVI • XML Schema adds to the validation of XML structures another concept: the decoration of each structure of the XML document with additional information. This is called the Post-Schema Validation Infoset, or PSVI • This can be useful for the downstream application, that can activate specific code depending on the PSVI data available for each element. • The most important contribution of the PSVI is without doubt the data type: validation code can assess that an element contains a valid date, a valid number, or a valid complex markup structure, so that the downstream application can skip any control on it and call appropriate handling code. Next: Unfortunately… 4/20

  5. Unfortunately… • … most schema languages cannot express all the structure and data constraints that document designers may need. • For example: • Mutual exclusion (“element x may have either the a attribute or the b attribute, but not both) • Deep exclusions (“element x cannot contain, at any level of its subtree, element y”) • Structure-dependent structures (“if the item is gratis (the attribute gratis is present), then no price should be specified (the element price should be absent)”) • Data-dependent structures (“if the address is a PO box, then the address must include a PO box number, otherwise it must include a street name and a street number”) • These kinds of constraints are known as co-constraints, or co-occurrence constraints. Most real life XML document types have one or more of those constraints. Next: Plenty of examples 5/20

  6. Plenty of examples • XHTML • “a elements cannot contain other a elements” (appendix B) • Both the normative DTD and the non normative XML Schema cannot express fully this requirement (they only express a weaker form: “a elements cannot directly contain other a elements”) • XSLT • “In a template element at least one of the match and name attributes must be present” • Again, the DTD and XML schema cannot express this requirement, and specify both attributes as optional. • XML Schema itself • “An element definition must either contain a ref or a name attribute, but not both. Furthermore, if the name attribute is present, then the type attribute or one of the simpleType or complexType elements must be present, but not two.” • The normative XML schema can only specify all these elements and attributes as optional. • … and plenty more… Next: Who cares? 6/20

  7. ? ? ? XMLdoc rules rules DOM tree downstream application DOM parser Not well-formed Schema validator DOM Tree + PSVI invalid Who cares? • Documents could contain violations to these rules, and still be considered valid according to the DTD or XML schema. • Three solutions: • Cross your fingers and hope for the best • Provide a default behavior (pick one option and ignore other structures) • Provide validation code within the downstream application incorrect Next: Schematron 7/20

  8. Schematron • Schematron could in fact express most of these requirements (but data- and structure-related structures only through hacks). • Schematron lacks generative rules, and they can be specified with great pain, or by mixing Schematron rules with grammar-based rules of another schema language. • Suggestions to use XML Schema and Schematron together in one schema document exist in literature. • Quite complex in practice, requires competence in both languages, and has problems with PSVI. Next: Extending XML Schema 8/20

  9. Extending XML Schema • Our view is that the only practical solution is to extend XML Schema (or another grammar-based language). • If the extension is minimal, then implementation costs, learning efforts, and impact on existing schemas are also minimal. Next: Our proposal: SchemaPath 9/20

  10. Our proposal: SchemaPath • SchemaPath is our proposal to minimally extend XML Schema to handle co-constraints of all kinds. • The idea is to find a way to conditionally assign types to elements and attributes. • Furthermore, a non-satisfiable type is added for specifying error conditions to avoid. • SchemaPath maintains the XML Schema syntax, adds only ONE construct and ONE pre-defined simple type, maintains important XML Schema properties (the validation theorem and round-tripping and reverse round-tripping properties), and does not impact the PSVI for valid documents. • Its simplest implementation is straightforward and trivial (~15 lines of code) in any language and architecture where an XSLT engine and an XML Schema engine already exist. • Qualified under namespace http://www.cs.unibo.it/SchemaPath/1.0, but the parser accepts also plain XSD schema namespace. Next: SchemaPath syntax (in one slide!) 10/20

  11. SchemaPath syntax (in one slide!) • <xsd:alt>: Expresses a condition in the type assignment of an element or an attribute. Its attributes are: • cond: an optional XPath expressing the condition that must be verified for the type assignment to be performed. Multiple conditions may be verified, in which case a priority mechanism is employed. An alt elements without an explicit cond attribute implicitly has a low-priority, default, always-true condition. • priority: an optional decimal number specifying the priority level of a condition, in case the default priority is unsatisfactory. • type: a required XML Schema type name which is assigned to the element or attribute if the condition holds and has the top priority. • xsd:error: a predefined unsatisfiable simple type. Assigning this type to an element or an attribute always determines a validation error. Next: A few examples 11/20

  12. A few examples • Mutual exclusion • “Element x may have either the a attribute or the b attribute but not both”. Suppose we have defined a type myType with both a and b attributes as optional <xsd:element name=“x”><xsd:alt cond=“(@a and @b)” type=“xsd:error”/><xsd:alt type=“myType”/> </xsd:element> • Data-dependent structures • “The element quantity must be an integer if the unit element is ‘items’, and it must be a decimal value if the unit element is ‘meters’”. Suppose we have already defined the data type for the unit element to only contain the values “meters” or “items”. <xsd:element name=“quantity”><xsd:alt cond=“../unit=‘items’” type=“xsd:integer”/><xsd:alt cond=“../unit=‘meters’” type=“xsd:decimal”/> </xsd:element> Next: Addressing co-constraints: XHTML 12/20

  13. Addressing co-constraints: XHTML • Deep exclusion of a elements within other a elements • “a elements cannot contain other a elements” • Suppose we have defined an inlineType to contain all inline elements that can go inside an a element, as well as inside other elements such as b, i, etc. <xsd:element name=“a”> <xsd:alt cond=“.//a” type=“xsd:error”/> <xsd:alt type=“inlineType”/></xsd:element> Next: Addressing co-constraints: XSLT 13/20

  14. Addressing co-constraints: XSLT • Minimal presence • “In a template element at least one of the match and name attribute must be present” • Suppose we have already defined a templateType type with the match and name attributes both set as optional <xsd:element name=“template”><xsd:alt cond=“@match or @name” type=“templateType”/><xsd:alt type=“xsd:error”/> </xsd:element> Next: Addressing co-constraints: XML Schema 14/20

  15. Addressing co-constraints: XML Schema • Complex mutual exclusions • “An element definition must either contain a ref or a name attribute, but not both. Furthermore, if the name attribute is present, then either the type attribute or one of the simpleType or complexType elements must be present.” • Suppose we have already defined an elementType with a choice of simpleType and complexType, and the type, ref and name attributes as optional. <xsd:element name=“element”><xsd:alt cond=“@name and @ref” priority=“2.0” type=“xsd:error”/><xsd:alt cond=“(@type or @ref) and (simpleType or complexType)” priority=“1.5” type=“xsd:error”/><xsd:alt cond=“../schema and @ref” priority=“1.0” type=“xsd:error”/><xsd:alt cond=“not(@name) and not(@ref)” priority=“0.5” type=“xsd:error”/><xsd:alt priority=“0.0” type=“element”/> </xsd:element> • The conditions could be simpler by using different complex types Next: Implementation: an XSD preprocessor 15/20

  16. X SPrules rules XSDrules X’ downstream application DOM parser XSDpreprocessor ok Nonwell-formed rules Schemavalidator invalid Implementation: an XSD preprocessor • SchemaPath validators can be implemented: • From scratch (but they have a complexity in the order of a XML Schema validator) • Modifying an existing XML Schema validator (breaking the evolution path of the selected validator) • As an XSD preprocessor (i.e. an independent application feeding a plain XML Schema validator) • It can be proved that SP validates X iff XSD validates X’ Next: Our XSLT-based process 16/20

  17. X SPrules rules XSDrules X’ XSLT T’’ XSLT MT XSLT T’ rules Our XSLT-based process • Our test preprocessor is implemented simply with two (rather convoluted) XSLT stylesheets and about 20 lines of real code. • The whole process uses a stylesheet T’ to create an XSD schema out of the SchemaPath, and meta-stylesheet MT to generate a stylesheet T’’ to transform the XML document X. The whole schema looks as follows: Next: An example of the final schema and XML doc 17/20

  18. This used to be the XPath“../unit=‘items’” This used to be the XPath“../unit=‘meters” An example of the final schema and XML doc • <xsd:choice> <xsd:element name="wrquantity0.2E.2E.2Funit.3D.27items.27"> <xsd:complexType><xsd:sequence> <xsd:element name="quantity" type="xsd:integer"/> </xsd:sequence></xsd:complexType> </xsd:element> <xsd:element name="wrquantity0.2E.2E.2Funit.3D.27meters.27"> <xsd:complexType><xsd:sequence> <xsd:element name="quantity" type="xsd:decimal"/> </xsd:sequence></xsd:complexType> </xsd:element></xsd:choice> • <invoiceLine> <unit>meters</unit> <wrquantity0.2E.2E.2Funit.3D.27meters.27> <quantity>2.5</quantity> </wrquantity0.2E.2E.2Funit.3D.27meters.27></invoiceLine> Next: Conclusions 18/20

  19. Conclusions • Support for co-constraints is heavily needed in many situations. • Many schemas and DTDs contain plain language specifications of co-constraints • Some document specifications even lament the lack of support for co-constraints in the schema language • The solution is to extend a schema language • One grammar, one validation, one schema document • The implementation as a pre-processor is a great aid. • Conditional type assignments are much cleaner than conditional types • The PSVI does not change • Good validity properties are preserved • Much simpler to implement Next: Thanks! 19/20

  20. Thanks! Visit us at http://genesispc.cs.unibo.it:3333/schemapath.asp or http://tesi.fabio.web.cs.unibo.it/schemapath/

More Related