[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] How big can the invoice number field be?
Stephen, Following on from this thought - being an old EDIr hack - and seeing its Feb' 13th today - one of those that promoted the use of XML/edi at its inception... EDI has two things - the formal transaction layouts - called IGs implementation guides. Loosely that equates to the core compontent dictionary and schema XSD in UBL. Now - EDI also has ICs - implementation conventions - that industry members published that spell out specific use patterns for their own needs and explicit transactions. That is the missing part here with UBL - how are you actually performing interchanges? Unfortunately EDI ICs are developed as Word documents - or proprietary mapper configurations - and hence people are writing code to match the ICs - which of course change - so the code and the ICs are never in step. Really CAM is designed in large part to provide the automated solution for all that in an open public sharable standard format. And take advantage of XML in ways that ICs simply cannot - such as supporting context - and linkage to codelists and registry metadata definitions - and business process logic. So when I look at all this - I see - while XML is better for many reasons we touted for XML/edi adoption - we've really not progressed much beyond the constraints that EDI and its interchange model shackled us with - with xsd and wsdl today. Only most recently with mash-ups and such - are we beginning to see people thinking outside the box in terms of what they can achieve with automated transaction exchanges... DW > -------- Original Message -------- > Subject: RE: [ubl-dev] How big can the invoice number field be? > From: stephen.green@systml.co.uk > Date: Wed, February 13, 2008 2:11 am > To: ubl-dev@lists.oasis-open.org > > Hi David > > Not me that's asking. I guess Thomas would prefer it if all this > was packaged up and maybe distilled down into just a few links. > The question asked was pretty simple. It just looks a tad like > the UBL solution is even more complex than the EDI one. I don't > think it needed to be like this, shame it has gotten a bit like > this though. In short I would say Thomas and others would need > a rule like 'UBL doesn't provide datatype length restrictions > (for database storage, etc) - use EDI ones' and maybe some > helpful ready-made artefacts to that end to aid interoperability > and conformance across implementations to make it real. > > -- > Stephen D. Green > > Partner > SystML, http://www.systml.co.uk > Tel: +44 (0) 117 9541606 > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > > > > Quoting "David RR Webber \(XML\)" <david@drrw.info>: > > > Stephen, > > > > I that regard - ping Pim @ OASIS - he is working on some XML to > > manage CPPA / XSD / CAM and MoU in a package that can then drive > > partner agreement SW - see also draft postings to CPPA documents area. > > > > DW > > > >> -------- Original Message -------- > >> Subject: Re: [ubl-dev] How big can the invoice number field be? > >> From: "Stephen Green" <stephengreenubl@gmail.com> > >> Date: Tue, February 12, 2008 12:06 pm > >> To: "David RR Webber (XML)" <david@drrw.info> > >> Cc: "G. Ken Holman" <gkholman@cranesoftwrights.com>, > >> ubl-dev@lists.oasis-open.org, fulton.wilcox@coltsnecksolutions.com > >> > >> Yes, well caught David :-) > >> > >> And of course you also need a framework (like ebXML with ebBP and ebCPPA) > >> to properly document all this in a potentially machine-processable > >> way. If not > >> using ebXML there might be some challenges e.g. with WSDL there doesn't > >> seem to be a way in WSDL itself to declare the extra datatype > >> restrictions for > >> runtime use. You might have to rely on design-time documentation and hard- > >> coding. I'm trying to see how far the OASIS TAG TC output might carry you if > >> you need to declare the restrictions with prose first - a nice > >> 'test assertion' > >> representation XML markup (if we produce one) should allow generation of > >> test suites (for conformance on a large scale warranting automated > >> repeatable > >> testing of many endpoints/parties), CAM, Schematron, HTML prose, whatever. > >> Worth keeping an eye on the OASIS TAMIE TC work too in this regard. Depends > >> how far you need to go and how many expected parties, etc. > >> > >> On 12/02/2008, David RR Webber (XML) <david@drrw.info> wrote: > >> > Stephen, > >> > > >> > Just getting caught up on email here. > >> > > >> > This of course is EXACTLY why you should be using CAM templates > >> to define the business interchange with your partners - overlayed > >> from the UBL schemas. > >> > > >> > CAM provides you all the tools to share with your partners such > >> constraints - contextually - so there are no surprises - and you > >> can mitigate the information flows as you need them by using > >> context variables so the processing knows exactly what template > >> profile applies to what business process step with your partner(s). > >> > > >> > Also - unlike schema - where its really tough to find where > >> contraints and definitions differ from the defaults - CAM makes it > >> immediately apparent - you can search on any set-length() functions > >> to discover what items are effected - and the HTML documentation > >> format includes field-by-field details so business analysts can > >> verify the functional rules without having to know schema or XML. > >> > > >> > Cheers, DW. > >> > > >> > > -------- Original Message -------- > >> > > Subject: Re: [ubl-dev] How big can the invoice number field be? > >> > > From: "Stephen Green" <stephengreenubl@gmail.com> > >> > > Date: Tue, February 12, 2008 12:35 am > >> > > To: fulton.wilcox@coltsnecksolutions.com > >> > > Cc: "G. Ken Holman" <gkholman@cranesoftwrights.com>, > >> > > ubl-dev@lists.oasis-open.org > >> > > > >> > > Plus, I have to confess to being a 'legacy' developer still working > >> > > on mainframes most of my time. But isn't it the fact that finance > >> > > systems all use a database. Surely there's nothing 'legacy' about > >> > > that. RDMS databases still all limit the field lengths don't they? > >> > > > >> > > On 12/02/2008, Stephen Green <stephengreenubl@gmail.com> wrote: > >> > > > I think it should be an issue for UBL that lack of a limit in UBL > >> > > > might encourage some to go over 35 characters. UBL should > >> > > > think about what problems that will lead to. Just how many > >> > > > systems out there are limited to something like 35 characters? > >> > > > My guess is it is 'still' a high percentage. > >> > > > > >> > > > I've seen limits on amounts, etc added to documents as a type > >> > > > of document-header-level metadata. Maybe this is a candidate > >> > > > for the UBLExtension. > >> > > > > >> > > > > >> > > > > >> > > > On 12/02/2008, Fulton Wilcox > >> > > > <fulton.wilcox@coltsnecksolutions.com> wrote: > >> > > > > Edifact invoices have an invoice length of 35 alpha-numeric > >> characters, so > >> > > > > that is a pretty good answer to the question of how long an > >> invoice number > >> > > > > can be. It is unlikely that any (or at least many) trading > >> partners will > >> > > > > have invoice-generating systems that create longer invoice numbers. > >> > > > > > >> > > > > If invoice number were in fact merely an identifying > >> number, 35 positions > >> > > > is > >> > > > > absurdly long - enough for each human being in the world to > >> generate 15 > >> > > > > trillion trillion invoices with unique IDs. Unfortunately > >> that field is > >> > > > > typically used as a composite string representing all sorts > >> of meaning, > >> > > > > hence the absurd length. If an invoice number has leading > >> zeroes, those > >> > > > > leading zeroes should not be lost in the enterprise to > >> enterprise handoff. > >> > > > > > >> > > > > Fulton > >> > > > Wilcox > >> > > > > Colts > >> > > > Neck Solutions LLC > >> > > > > > >> > > > > > >> > > > > > >> > > > > -----Original Message----- > >> > > > > From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] > >> > > > > Sent: Monday, February 11, 2008 7:52 PM > >> > > > > To: ubl-dev@lists.oasis-open.org > >> > > > > Subject: Re: [ubl-dev] How big can the invoice number field be? > >> > > > > > >> > > > > At 2008-02-11 16:41 -0500, Tobey, Thomas N. wrote: > >> > > > > >Greetings! > >> > > > > > >> > > > > Welcome! > >> > > > > > >> > > > > >I've been trying to find a standard recommendation for how > >> > > > > >long the invoice number field can be. I tried to find it in the UBI > >> > > > > >specification. > >> > > > > > >> > > > > UBL does not constrain the length of fields. Any element and any > >> > > > > attribute can have any length, according to the schema. Trading > >> > > > > partners can layer on top of the schema constraints > >> whatever business > >> > > > > constraints they wish to have, including length-related constraints. > >> > > > > > >> > > > > In the UBL committee there is a long-identified task (as yet > >> > > > > unfulfilled) to identify some length-related value > >> constraints to add > >> > > > > to a layer separate from the schema. It was thought these would be > >> > > > > built into the second-pass Schematron constraints as they > >> are ideally > >> > > > > suited for such validation. > >> > > > > > >> > > > > If you check at the bottom of this page: > >> > > > > > >> > > > > > >> > > > http://lists.oasis-open.org/archives/ubl/200801/msg00008.html > >> > > > > > >> > > > > ... you will see reference to consulting specifications such as > >> > > > > UNTDED, which does have length-related constraints, to add to the > >> > > > > second pass layered on top of the non-length-restricted schema > >> > > > constraints. > >> > > > > > >> > > > > >I'm sure my company will have a limitation in our payment system. > >> > > > > >However, I was just wondering if there was a standard that > >> the "world" > >> > > > > >is moving toward. > >> > > > > > >> > > > > I'm more the geek than the business expert, so I'll let the business > >> > > > > experts answer that aspect of your post. Though you may find the > >> > > > > UNTDED may help: > >> > > > > > >> > > > > http://www.unece.org/cefact/standar/docs/tded.htm > >> > > > > > >> > > > > But from my geek perspective, what more can you say about > >> limitations > >> > > > > in the payment system? Having worked with XML and SGML for many > >> > > > > years, my understand of length-related value constraints on > >> > > > > information fields are based on archaic legacy systems. These > >> > > > > systems were typically supported by programming languages with > >> > > > > inherent field limitations, and I recall my work in COBOL when > >> > > > > thinking of this. Programming languages and data sets > >> these days may > >> > > > > not need length-related constraints, so I would not launch into your > >> > > > > development assuming that these are obligatory. > >> > > > > > >> > > > > If you can share your requirements in this area, I'm confident many > >> > > > > people on this list would be interested to know how relevant such > >> > > > > legacy constraints are these days in modern systems implemented with > >> > > > > modern languages. > >> > > > > > >> > > > > >We're implementing a new procure to pay process now. > >> > > > > > >> > > > > Wonderful! I hope you find UBL suits your needs! > >> > > > > > >> > > > > . . . . . . . . . . . . . Ken > >> > > > > > >> > > > > -- > >> > > > > World-wide corporate, govt. & user group XML, XSL and UBL training > >> > > > > RSS feeds: publicly-available developer resources and 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 Nov'07 > >> > > > http://www.CraneSoftwrights.com/u/bc > >> > > > > Legal business disclaimers: > >> > > > http://www.CraneSoftwrights.com/legal > >> > > > > > >> > > > > > >> > > > > > >> > > > --------------------------------------------------------------------- > >> > > > > To unsubscribe, e-mail: > >> > > > ubl-dev-unsubscribe@lists.oasis-open.org > >> > > > > For additional commands, e-mail: > >> > > > ubl-dev-help@lists.oasis-open.org > >> > > > > > >> > > > > > >> > > > > > >> > > > --------------------------------------------------------------------- > >> > > > > To unsubscribe, e-mail: > >> > > > ubl-dev-unsubscribe@lists.oasis-open.org > >> > > > > For additional commands, e-mail: > >> > > > ubl-dev-help@lists.oasis-open.org > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Stephen D. Green > >> > > > > >> > > > Partner > >> > > > SystML, http://www.systml.co.uk > >> > > > Tel: +44 (0) 117 9541606 > >> > > > > >> > > > http://www.biblegateway.com/passage/?search=matthew+22:37 > >> > > > .. and voice > >> > > > >> > > > >> > > -- > >> > > Stephen D. Green > >> > > > >> > > Partner > >> > > SystML, http://www.systml.co.uk > >> > > Tel: +44 (0) 117 9541606 > >> > > > >> > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > >> > > > >> > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > >> > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > >> > > >> > >> > >> -- > >> Stephen D. Green > >> > >> Partner > >> SystML, http://www.systml.co.uk > >> Tel: +44 (0) 117 9541606 > >> > >> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > >> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]