OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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


> 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 (which I already have quite a
lot of experience in) and XSL-FO (with which I have a little
experience from around 2 years ago, when I last tried doing handling
my invoices through XML -- but I don't think UBL was available then).

> You've found the right place to ask!  I can answer some questions,
> and others can address the other questions or disagree with mine.

Good! One other question I forgot to ask in the last email: why was
XML Schema used for UBL instead of RELAX NG, 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.

> This kind of information can be found from the schemas, but W3C
> Schema expressions (for any model) are notoriously difficult to
> read.  One available resource that may help you find such things is
> the list of valid XPath addresses for the information items described
> by the W3C Schema expressions:
>
>    http://lists.oasis-open.org/archives/ubl/200410/msg00002.html
>
> In there you will find complete enumerations of the information items
> possible in a UBL instance, indicated by their respective XPath address.

Right. I think there's an elaborate list of XPath expressions
somewhere in the UBL package as well, but I didn't think it was too
human-friendly -- but it seems that's just the state of things for
now.

> I'll let someone else address this as I don't know if you can use an
> existing information item or if you will need to add a new
> information item.  I'm curious myself.

> I see this (and saw this when I wrote the stylesheets available on
> our web site) as a presentation issue and not an information
> issue.  Thus, I see this as an issue of the way the information is
> presented to users, not in the way information is coded for users.

I think that makes sense; 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?

> 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.

> Ahhhhhhhhh ... code lists ... another religious topic ... looking at
> the XSD declaration of @quantityUnitCode you'll see that there is no
> specification of a value to use.  You get to make up your own!  But,
> that doesn't sound very portable, does it?  So, when two trading
> partners need to agree on codes to use where codes are not specified,
> they need a formal way of declaring the codes upon which they agree,
> and the places where they can be used.  The UBL team is reviewing a
> candidate OASIS standard to do this, and comments from UBL-Dev
> members are *most* welcome:
>
>    http://www.oasis-open.org/archives/ubl-dev/200512/msg00034.html
>
> For now, make up your own code and I think you are going to have to
> pull something out of the air on your own.  I think XSD durations are
> inappropriate as the value incorporates the units of measure, though
> there are cases where this can be useful.  So are iCal
> http://www.ietf.org/rfc/rfc2445.txt durations.  Given that UBL uses
> CCTS which uses only a decimal value and a single coded unit of
> measure, I'm not sure which you could use, but probably just "H" and
> a value of 1.5 would do.

Interesting suggestion. I guess it will do, although 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.

> 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.

> Who is to say what you're doing is non-standard?  This is wonderful
> to see you trying to apply the standard to your own situation.
>
> Please keep us all informed of your progress ... good luck!

I've made good progress representing the invoices as UBL and mostly
have an XSLT stylesheet figured out for displaying the invoice as
XHTML. 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. 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).

> I hope this helps.

It helps a lot, thanks for the elaborate reply!

Regards,

Manuzhai


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