OK, now on [pause].
for the UBL calculation model.
The other advantage of using XPath ...
to say something about the
schema (e.g. to extract a dictionary entry name if you really need one)
or doc($instance)/Invoice/... to assert something about the invoice
(where another reference
defines $instance), e.g. using a variable assignment element of the
xpath-profile test assertion ]
... is that you can make the assertion(s) executable. You can perhaps
convert to Schematron
for individual assertions or if you want to chain the assertions (make
one dependant on the
outcome of testing an invoice according to another) you can
(eventually) use a test assertion
xpath profile execution engine. For the latter you may need to wait
for tools to be in production
or write your own but WS-I is doing the latter quite successfully and
I hope there will be tools
soon, perhaps some free ones.
The Balisage 2009 XML conference will feature a presentation on this
by Jacques Durand of
Fujitsu US / WS-I / OASIS (TAG Chair, TAB, etc) which should be
excellent (plus Ken and I
both get a mention!).
Stephen D Green
Sorry to jump in gents but I was looking to build this myself however you
gentleman know your way around these datasets better than I do and I am
hoping you may already have same.
Do we have a list of BBIE's that may play a role in calculating the
balance of an amount in an invoice?
You can see that Stephen and I have started here:
... where you can see we are using "nsprefix:UBLName" and definition,
assuming a documentary set (not required set) of namespace prefixes listed
here:
I am talking all BBIE's that could form part of a calculation.
This would include a price in a catelogue that may transfer to an order.
This would not include the address of a supplier.
A list that would be useful would be:
UBL Name | Object Class | Property Term | Data Type | Definition
Given that "nsprefix:UBLName" combination will uniquely find the other
information, and that applications will use "nsprefix:UBLName" for access to
the information from programs or from stylesheets, I suspect our level of
detail is sufficient.
One drawback to your proposed list is that it doesn't show context (many UBL
business entities are used in multiple contexts), so I'm proposing an XPath
pattern address to the item in question and then a relative XPath address to
the components on which it is based. The information you want can be
derived unambiguously from the "nsprefix:UBLName" components used in the
XPath addresses.
For example, consider the common library entry:
TaxTotal | Tax Total. Tax Amount. Amount | The total tax amount for ...
This has different contexts just in our first examples:
/in:Invoice/cac:TaxTotal/cbc:TaxAmount
/in:Invoice/cac:InvoiceLine/cac:TaxTotal/cbc:TaxAmount
... so your level of granularity would not distinguish these two different
contexts.
If not I will try and build one myself.
It would help if you could join the committee and contribute to the work of
the HISC. If not, then submitting your contributions through the official
TC comment page is the way to have the committee formally consider your
input:
Thanks!
. . . . . . . . . . . Ken
--
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
---------------------------------------------------------------------