XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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-assertions_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</LegalMonetaryTotalLineExtensionAmount>
   <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
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS