[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] [Summary] Portable Data Components
- From: "David Lee" <dlee@calldei.com>
- To: <stephengreenubl@gmail.com>, "'Costello, Roger L.'" <costello@mitre.org>
- Date: Tue, 12 Apr 2011 06:43:24 -0400
This looks like the perfect case for schematron ...
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
-----Original Message-----
From: Stephen D Green [mailto:stephengreenubl@gmail.com]
Sent: Tuesday, April 12, 2011 2:33 AM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] [Summary] Portable Data Components
By way of further example of portability (though perhaps more
composability).
Say I have to write something to test UBL invoices that their
totals are correct, etc. Say I write for a community which wants
me to define some semantics formally so they all use the same
totalling calculations when sending and receiving invoices. I
might follow this workflow:
1) spec out the semantics with rules for the calculation of totals
2) write test assertions (TAs) for anyone testing the invoices
3) produce a reusable set of test cases referring to the TAs
It is important the test cases refer to the test assertions and the
test assertions refer to the statements in the spec and always 1:1.
I want people to be able to substitute rules for sub-communities
say in other countries where the rules have to be slightly different.
I can use XML Schema 1.1 with assertions for the test cases (3)
but they have to be separable from each other so people can
customise the rules and take one TA and not another and insert
new ones to fit alongside those already there. I have to pull totals
and amounts out of the invoice into another XML document so
that some calculations can be performed outside the XSD and it
is this secondary XML document which I define with the assertions
in XSD 1.1.
I tried it and it kind of works. I wrote it up very roughly in a blog
here (but it's rather long winded as I wrote it too hurriedly)
http://stephengreenxml.blogspot.com/2011/04/document-engineering-test-assert
ions_10.html
The rules from step 1 are here
http://lists.oasis-open.org/archives/ubl-comment/200910/msg00012.html
I end up with these bits of XSD 1.1 but I'm not sure they are as portable
and composable as they need to be
<xs:element name="IN1">
<xs:complexType>
<xs:sequence>
<xs:element name="InvoiceCount">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:assertion test="$value ge 1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="INTOT1">
<xs:complexType>
<xs:sequence>
<xs:element name="DistinctCurrencyCount">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:assertion test="$value eq 1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="LegalMonetaryTotalLineExtensionAmount">
<xs:simpleType>
<xs:restriction base="xs:int"/>
</xs:simpleType>
</xs:element>
<xs:element name="SumOfLineExtensionAmounts">
<xs:simpleType>
<xs:restriction base="xs:int"/>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:assert test="SumOfLineExtensionAmounts eq
LegalMonetaryTotalLineExtensionAmount"/>
</xs:complexType>
</xs:element>
The tests use this interim scratch pad of totals copied and derived from
the UBL invoice (perhaps using XSLT)
<IN1>
<InvoiceCount>1</InvoiceCount>
</IN1>
<INTOT1>
<DistinctCurrencyCount>1</DistinctCurrencyCount>
<LegalMonetaryTotalLineExtensionAmount>100</LegalMonetaryTotalLineExtensionA
mount>
<SumOfLineExtensionAmounts>100</SumOfLineExtensionAmounts>
</INTOT1>
Ideally I'd want the rule INTOT1 and other rules to be ignored if IN1 fails.
I can get that sort of functionality using executable XPath test assertions
and a tool called Tamelizer (on Google Code). Not sure I'd get it with XSD.
Also I'd like to report on outcomes and I'm not sure XSD 1.1 gives me that.
Best regards
----
Stephen D Green
On 10 April 2011 14:24, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> Here is a summary of the discussions we have had over the last few weeks
on portable data components (including yesterday's excellent discussion):
>
>
http://www.xfront.com/xml-schema-1-1/best-practice/portable-data-components/
Portable-Data-Components.pdf
>
>
> We are still seeking good examples of portable data components, so if you
have an example please speak up.
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]