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

Apologies, I don't wish to imply this wouldn't normally be done
with Schematron. I haven't yet tried Schematron myself for this.
I think even a bit of C# or Java code running a list of XPaths
would do it too and handle any prerequisite (as XPaths) for a
TA. It occurs to me though that this is an example of a situation
where each component needs to be kept self-contained so
that it can be portable and this might determine how test cases
are written and even, by follow-through, how TAs are written
and maybe even how specs might better be written. I think,
from what I've heard from others, there would be a few challenges
to overcome if you were to use Schematron though (e.g. how
to apply several tests to the same context and prerequisites),
just as perhaps with XML Schema 1.1, especially given a lot of TAs.
----
Stephen D Green



On 12 April 2011 11:43, David Lee <dlee@calldei.com> wrote:
> 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]


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