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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: [ubl-lcsc] Re: Draft mapping for stylesheets

See responses in line....

G. Ken Holman wrote:

> At 2003-01-30 14:59 +0800, Tim McGrath wrote:
>> As discussed I have attempted to map the 0p70 elements to your layout 
>> forms.
> Thank you!
>> Please find attached the initial results.  Rather than fax the 
>> handwritten forms, I updated your HTML notes - i hope that is OK for 
>> you.
> Perfect, Tim ... that is better than a fax.  Some have had problems 
> with the large diagnostic files on their machines of limited memory 
> (I've documented a warning about the very large diagnostic files), but 
> from what I can tell it seems that you were able to use them.
> BTW, for those with limited memory on their machines the text-based 
> diagnostic files (e.g. 220order0.key.rpt.txt) can be read by a simple 
> text editor without crashing your machine while the HTML-based 
> diagnostic files (e.g. 220order0.key.rpt.html) could very well crash 
> your session.  If you can use the HTML, though, then clicking on the 
> XPath expressions in the HTML report from an IE browser will copy the 
> XPath address to the clipboard for pasting into your documentation.
> By documenting the fields formally with the XPath expressions and 
> accompanying text, I'm anticipating this will be unambiguous ... I'm 
> looking forward to going through what you've sent, Tim.
> It would be nice if the input from all members of the team could (1) 
> indicate their interpretations of the XPath addresses for the fields, 
> and (2) feed back to me the efficiency of specifying their needs using 
> the methods that I've created and provided here (this is the first 
> time I've worked with a team in this fashion and only guessed at what 
> would be useful tools).

i must confess to onyl editing the HTML files and not the click through 
XPath - i manually edited the path names - so there may be inconsistencies.

>> 1. In building the Invoice and Despatch Advice, I revisited the Order 
>> form and updated some fields there as well.  I also suspect that the 
>> documentation needs updated since the last 'booger' release :-[
> Probably ... I was reluctant to invest a lot in the documentation 
> before the schemas were finalized.

I guess we can fix these up prior to the supplemental release (Feb 
10th).  If you haven't the time maybe we can do this via QA?

>> 2. We appear to be missing (or at least ambiguosuly defined) some 
>> components of the Despatch Advice. In particular the Vessel/flight No 
>> - for which i could find not meaningful equivalent. [[NB This should 
>> be logged somewhere in the 'issues' list ]]
> Is this an "issue" for me, or for LCSC or NDRSC? 

Sorry, i was unclear - this is an LC issue.

>> 3. w.r.t. the Invoice. - the form has no places for 
>> allowances/charges and tax details.  I suspect we should adopt common 
>> business practice and put these under the list of Items, using the 
>> Description and Amount columns.  However this makes the mapping rules 
>> quite tricky - so i have ignored them in this first draft.
> Well ... use your imagination and tell me what you want to see, and 
> I'll let you know if they are too tricky or not.

OK I will send my ideas in the enxt suite of mappings.

>> Let me know if this is suitable and i will carry on with the other 
>> forms.
> I haven't delved deep into them yet, but I will let you know.
> At 2003-01-30 15:05 +0800, Tim McGrath wrote:
>> 4. In cases of line extension of prices and summary totals, we do not 
>> want to have these calculated.  The XML documents will carry these 
>> totals and we should use these.
> Really?  I saw them in 0p65 but I couldn't recognize them in 0p70 so I 
> did the calculations.  Jean also thought at one point that they might 
> be calculated, but wasn't sure.  I'll look through your submission and 
> make the appropriate changes to use the values as given.
>> Perhaps you may wish to calculate and compare them then alert of 
>> differences, but it isn't safe to assume they must match.  Business 
>> rules always follow the transmitted totals.
> Then I won't flag discrepancies.  I'll take what I receive as gospel 
> and blindly display the values.

thanks - you should find the appropriate mappings now.

>> 5. Apart from a few typos on my behalf, i had to invent and use 
>> qualifiers for the Invoice and Despatch Advice elements.  I opted for 
>> 'in' and 'da'.  Am i correct in doing this?
> Yes, actually the diagnostic files already give you the prefixes that 
> I am assuming in my stylesheets (although prefixes are arbitrary, 
> using the ones in the diagnostic files will be consistent with my 
> stylesheet files):
> T:\ssdebug\380inv\test>head 380inv0.key.rpt.txt
> 1   /in:Invoice/cat:ID
> 1.1 /in:Invoice/cat:ID/@language
> 1.2 /in:Invoice/cat:ID/@schemeAgencyID
> 1.3 /in:Invoice/cat:ID/@schemeAgencySchemeAgencyID
> 1.4 /in:Invoice/cat:ID/@schemeAgencySchemeID
> 1.5 /in:Invoice/cat:ID/@schemeDataURI
> 1.6 /in:Invoice/cat:ID/@schemeID
> 1.7 /in:Invoice/cat:ID/@schemeURI
> 1.8 /in:Invoice/cat:ID/@schemeVersionID
> 1.9 /in:Invoice/cat:ID/@UID
> T:\ssdebug\380inv\test>cd ..\..\351dsadv\test
> T:\ssdebug\351dsadv\test>head 351dsadv0.key.rpt.txt
> 1   /da:DespatchAdvice/cat:ID
> 1.1 /da:DespatchAdvice/cat:ID/@language
> 1.2 /da:DespatchAdvice/cat:ID/@schemeAgencyID
> 1.3 /da:DespatchAdvice/cat:ID/@schemeAgencySchemeAgencyID
> 1.4 /da:DespatchAdvice/cat:ID/@schemeAgencySchemeID
> 1.5 /da:DespatchAdvice/cat:ID/@schemeDataURI
> 1.6 /da:DespatchAdvice/cat:ID/@schemeID
> 1.7 /da:DespatchAdvice/cat:ID/@schemeURI
> 1.8 /da:DespatchAdvice/cat:ID/@schemeVersionID
> 1.9 /da:DespatchAdvice/cat:ID/@UID
> T:\ssdebug\351dsadv\test>
> Thanks again, Tim ... I'm looking forward to working with your input 
> and will report back on the use of your information.
> ...................... Ken
> -- 
> Upcoming hands-on in-depth   Europe:         February 17-21, 2003
> XSLT/XPath and/or XSL-FO     North America:      June 16-20, 2003
> G. Ken Holman                mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
> ISBN 0-13-065196-6                      Definitive XSLT and XPath
> ISBN 0-13-140374-5                              Definitive XSL-FO
> ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
> ISBN 1-894049-10-1              Practical Formatting Using XSL-FO
> Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc

tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 

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

Powered by eList eXpress LLC