Re: [ubl-dev] UBL Newbie -- invoices

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-01-14 21:22 +0100, Manuzhai wrote:
> > There are freely downloadable stylesheets for producing PDF and HTML
> > ... just follow the "Free resources" hyperlink at the right edge of
> > our home page linked in my trailer below.
>
>Yes, I saw those -- but I want a custom layout, and I don't mind
>getting my hands dirty with both XSLT

Great!  They are not provided to be used in-toto, though they can be 
(and there is even an XSL-FO to PDF engine supporting the stylesheets 
in-toto), they were provided to give folks a start and to show it can be done.

>Good! One other question I forgot to ask in the last email: why was
>XML Schema used for UBL instead of RELAX NG,

It was surely not my choice as I wanted to use RELAX-NG, but you 
could review the committee archives to see the debate.  It was 
considered that W3C Schema was more "standard" (RELAX-NG didn't 
become ISO/IEC 19757-2 until later, but it is an ISO standard now) 
and that there was more vendor support.

But, note that the W3C Schema expressions are merely synthesized from 
the collaborative spreadsheets.  One could mimic such synthesis to 
produce RELAX-NG expressions, but they would not be considered 
normative.  Only the W3C Schema expressions are normative.

>which I consider much
>easier to read and is an OASIS standard? Is there a good reason for
>this? I didn't think it makes much sense.

My recollection of the debate is that it was purely vendor support at 
the time ... the RELAX-NG co-occurrence constraints would have been 
powerful tools.

>Right. I think there's an elaborate list of XPath expressions
>somewhere in the UBL package as well,

Nope ... these followed afterwards.  Since the W3C expressions were 
regularly structured (as a result of having been synthesized), I was 
able to write XSLT to synthesize the XPath addresses from reading the 
schema files.

>but I didn't think it was too
>human-friendly -- but it seems that's just the state of things for
>now.

*Please* recommend to the committee any improvements you can think of 
for better presenting information published by the committee.  We are 
creating this information for our own use and for the public use, and 
we need to hear your (and everybody else's) opinions on how to make 
them better.

*That's* a big reason for UBL-Dev ... to get non-committee input 
regarding committee efforts.

>but where exactly is the border between
>information that has to be in the Invoice document, and information
>that is only added in some presentation layer? Obviously, that's a
>sliding scale, but are there any guidelines?

It is a religious question ... I don't think you'll find guidelines, 
just people's opinions.  My opinion is that each case is unique and 
one needs to consider if a piece of information "belongs" as an 
information item or as an annotation, and then as what kind of annotation.

> > I'll defer to the business subject matter experts (I'm just an XML
> > geek) but my guess would be to use the generic cbc:Note element to
> > carry supplemental information such as this.
>
>Right -- but where to put it? Judging from the other uses of cbc:Note,
>it should probably be inside some other element that provides the note
>with some meaning.

But "meaning" is in the eye of the beholder.  If you want to 
*process* that the invoice is for a particular project, then that 
sounds semantic enough to me to have to create an information item 
(element or attribute) to store it, but then you get into the (as yet 
still not completely defined) methods of extension and customization.

>I also have many
>places where the quantity doesn't really apply (in many services, I
>just make my clients pay for the work instead of per hour). I haven't
>tested if I can just leave the thing out, but I guess I should try.

I see in the XPath file for Invoice, information item 878, that the 
cardinality for this information item indicates it can be left out.

> > BTW, which example has an exclamation mark for such a value?
>
>In the UBL package, I've mainly looked at
>/xml/office/UBL-Invoice-1.0-Office-Example.xml, which has an
>exclamation point as a value there.

Ah, I see it now, I had inadvertently opened the Order example.  I 
would think this is an oversight and it has no meaning at all.  That 
the schema only allows a normalized string means that it is 
schema-valid, just not meaning-valid.

>I've made good progress representing the invoices as UBL and mostly
>have an XSLT stylesheet figured out for displaying the invoice as
>XHTML.

Kewl!

>I have to say, it does seem like trade partners have to figure
>out an awful lot to be able to use this standard effectively.

Indeed ... though the alternative would be to constrain trade 
partners too much that they feel they can't use the standard at 
all.  It is a balance that can, I believe, only be determined through 
practical experience.

>I'm
>thinking there should probably be available default codelists with
>some sane default codes for use by trade partners who aren't doing
>anything crazy with this (and human-friendly documentation of these
>codelists).

A noble effort ... are you in a position to join the committee and 
contribute?  As you can see we are working on a number of code list issues.

Or, you could even start a grassroots effort of defining 
genericode[1] files for such use by trading partners.

Good luck!

. . . . . . . . . Ken

[1] http://www.genericode.org/


--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal