[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: SV: [ubl] Guidance sought regarding full UBL 2 XPath files
Hmm, it would be nice to have some estimates as to when/how often/under what conditions documents would expand to this actual size. Actually a project that I'm trying to get okayed in here would provide the danish government with datamining capacities to show distribution of element usage among instances (a very tertiary benefit) Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sendt: 26. januar 2006 02:41 Til: G. Ken Holman Cc: ubl@lists.oasis-open.org Emne: Re: SV: [ubl] Guidance sought regarding full UBL 2 XPath files I do not see this 'explosion' as anything negative. In fact, it reflects how much more versatile UBL 2.0 is. No-one expects any document instance or any implementation to use all these possible assemblies. Deepending on requirements and business rules, different paths will be used. In other words, six to eight times more contexts of use! (in fact it is probably a logarithm of 6 or 8). The SBS is one example of this. G. Ken Holman wrote: > At 2006-01-25 16:14 +0100, Bryan Rasmussen wrote: > >> looking over this quickly it looks to me that Order related documents >> have >> an expansion of approx. 8 times, the expansion of invoice looks like >> approx. >> 6 times (this is on the element level) >> >> The advice documents (DespatchAdvice,ReceiptAdvice) seem to have a >> different >> expansion, approx. double >> >> anyone have any ideas as to which elements this would be likely to be? > > > Per the excellent suggestion in this morning's session at the > face-to-face, I grabbed the two smallest XPath report files and the > smallest of the larger report files for both UBL 1 and UBL 2 and put > them in the a file in the temporary folder of the documents page: > > http://www.oasis-open.org/committees/download.php/16404/XPath-comparison-fil es-20060125-1950z.zip > > > It would seem the explosion comes from the addition of: signature > information, many more roles of parties involved, and document and > item identification constructs. > > Perhaps we just have to live with it. Am I ever glad we have the SBS! > > I hope this helps. > > . . . . . . . . . . . . . . . . Ken > > > -- > 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/o/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services http://www.docengineering.com/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]