[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [Summary] Portable Data Components

• From: Stephen D Green <stephengreenubl@gmail.com>
• To: xml-dev@lists.xml.org
• Date: Thu, 14 Apr 2011 09:14:07 +0100

I think in reality the portability of the Schematron is hindered by
the namespaces (ironically). The namespaces in the example are
not an issue because there are none declared in my 'scratchpad'.
If there were namespaces then we have two alternatives, at least
one of which hinders portability. (And without the 'scratchpad'
intermediary XML, the Schematron schema would have to handle
multiple namespaces when dealing with UBL invoices, for example,
and you'd still be looking for scalable portability/modularity too.)

Option 1: make the XPaths handle the namespaces whatever the
prefix(es) used. I forget how to do this succinctly with XPath 2. If
you stick to (or are stuck with) XPath 1 you can make the expressions
independant of the prefix(es) using something like this I think:
*[local-name()='MyElement'][namespace-uri()='my.namespace']

Option 2: use the 'sch:schema/sch:ns' element in Schematron

Option 1 gets messy and might overstretch the processors
Option 2 seems to me to limit the portability of any 'sch:pattern'
in the Schematron schema because the XPaths are then tightly
bound to the schema and its namespace declarations

I reckon you either need a better way to make the expressions
independant of the namespace/prefix (which itself hides reduced
portability behind that removed prefix since foreign namespaces
will now not be distinguished, I think) or Schematron might perhaps
support more portable patterns by allowing the sch:ns element to
be a child of the sch:pattern. The latter might be a pain to
implement but I think would improve Schematron.

Cheers

Steve

----
Stephen D Green



On 13 April 2011 22:07, Stephen D Green <stephengreenubl@gmail.com> wrote:
> I guess the Schematron equivalent has the advantage of simplicity and
> doesn't lose out on portability if any prerequisites are merely turned
> into qualifications on the context:
>
> <schema xmlns="http://purl.oclc.org/dsdl/schematron">
>    <pattern>
>        <rule context="/InvoiceCalculationModelReport/IN1[1]">
>            <assert test="InvoiceCount[1]='1'">IN1 Failed</assert>
>        </rule>
>    </pattern>
>    <pattern>
>        <rule context="/InvoiceCalculationModelReport/INTOT1[1][DistinctCurrencyCount[1]='1']">
>            <assert
> test="LegalMonetaryTotalLineExtensionAmount[1]=SumOfLineExtensionAmounts[1]">INTOT1
> Failed</assert>
>        </rule>
>    </pattern>
> </schema>
>

• References:
  • [Summary] Portable Data Components
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: [Summary] Portable Data Components
    • From: Stephen D Green <stephengreenubl@gmail.com>
  • RE: [Summary] Portable Data Components
    • From: "David Lee" <dlee@calldei.com>
  • Re: [Summary] Portable Data Components
    • From: Stephen D Green <stephengreenubl@gmail.com>
  • Re: [Summary] Portable Data Components
    • From: Dave Pawson <davep@dpawson.co.uk>
  • Re: [Summary] Portable Data Components
    • From: Stephen D Green <stephengreenubl@gmail.com>