[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Newbie -- invoices
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]