Transcript PEPPOL Development

Document Validation for PEPPOL
Philip Helger
Austrian Federal Computing Centre
February 11th 2010
Version 1.0
Why validation is important
• Different countries have different
requirements (data formats, middleware,
legislation)
• All business documents are in UBL while
within the PEPPOL infrastructure
• Fail as early as possible
Types of validation
• Technical validation (document structure)
– XML Schema
– RelaxNG (+ Compact)
–…
• Semantic validation
– Schematron
– XSLT
– CAM (Content Assembly Mechanism)
– ….
Layered validation
Bilateral
(Schematron)
Country independent
Somehow
specific
(Schematron)
• Industry requirements
• National requirements
CEN Profile
specific
(Schematron)
Basic (Schematron)
Technical structure (XSD/RNG)
Transformation and
validation workflow
Source format
PEPPOL scope
Sending
entity
Full UBL transformation
Destination country UBL validation
=
PEPPOL tube
Validate incoming UBL
Receiving
entity
Transform to destination format
Legend:
Destination format
Optional/national
To be implemented
WP8 specified
Validation issues
• Validation is required for each country to
check if the national requirements are fulfilled
– Maybe national + industry specific validations
required
• Validation is required only for UBL format
• Version issues
– National validation rules may change
– The validation itself can have different versions
Schematron
• High level validation language
• XML based
• Different versions available – we’re using ISO
Schematron
• Uses XPath for node context determination
• Differentiates between reports and assertions
• Result is an SVRL (Schematron Validation Result
List) XML document
• Visit www.schematron.com for details
How to apply Schematron
• Schematron is applied to an XML document
– The Schematron itself is transformed to an XSLT
script
• The transformation is done via XSLT
• The XSLT scripts are provided by schematron.com
– Result in an SVRL document
• Transformation works with Saxon
Schematron example
<schema xmlns="http://purl.oclc.org/dsdl/schematron">
<ns uri="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" prefix="cac"/>
<ns uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" prefix="cbc"/>
<ns uri="http://www.ebinterface.at/schema/3p0/" prefix="eb"/>
<pattern name="Order">
<rule context="//cac:OriginatorDocumentReference">
<assert test="cbc:DocumentType and cbc:DocumentType != ''">
BII-T01-003: DocumentType text Must be given for Originator Document Reference</assert>
</rule>
<rule context="//cac:AdditionalDocumentReference">
<assert test="cbc:DocumentType and cbc:DocumentType != ''">
BII-T01-004: DocumentType text Must be given for Additional Document Reference</assert>
</rule>
<rule context="//cac:Contract">
<assert test="(cbc:ID and cbc:ID != '') or (cbc:ContractType and cbc:ContractType != '')">
BII-T01-006: If Contract ID not specified Contract Type text SHOULD be used for Contract
Reference</assert>
</rule>
<rule context="//cac:Delivery/cac:RequestedDeliveryPeriod">
<assert test="translate(cbc:EndDate, '-', '') &gt;= translate(cbc:StartDate, '-', '')">
BII-T01-009: A delivery period end date SHOULD be later or equal to a start date</assert>
</rule>
<rule context="//cac:Price">
<assert test="cbc:PriceAmount &gt;= 0">
BII-T01-026: Price of item must be positive or zero</assert>
</rule>
</pattern>
</schema>
Schematron pitfalls
• Only reports and assertion  no real error
level handling
– Use different Schematron rule sets for different
error levels
• Not the full flexibility of XSLT
– The Schematron is the one provided by PEPPOL
but you are free to apply additional validation
rules in your solution
Demo
• Live Demo on Schematron validation
Summary
•
•
•
•
•
•
Only UBL needs to be validated
Technical validation using XSD
Semantic validation using ISO Schematron
Stacked validation required
Test suite to be created
Standalone validation service to be provided
Q&A
• Contact me:
[email protected]
• Slides will be published
• Validation tool will be published