[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?
And it seems that most EDI and equivalent XML standards (perhaps cXML is an exception of course) inherited a lot from EDIFACT in one way or another so probably the best advice is Fulton's - to default to the EDIFACT datatype length restrictions. There is, as it happens, just one restriction beyond the schema constraints in UBL - no zero length strings allowed - but as it happens I'm asking for that to be reconsidered as it causes problems with things like XForms. So this seems to back up Ken's view that one man's meat is another man's poison and UBL would want to avoid setting such a standard in stone. I do agree with you though that there needs to be some arbitration. I think it only needs to cover key fields like identifiers and maybe names and perhaps not descriptions. I hope UBL will indeed take this on and there will be the resources to carry it through - recommending defaults say. So for which datatypes to provide default restrictions? I guess this has to be decided within the IPR-controlled environment of the OASIS TC process but here are some thoughts as a kind of survey. Would you agree with these to start with? identifiers? yes - UUIDs maybe 256, IDs maybe 35 names? yes - maybe whatever is widespread in EDIFACT amounts? maybe no - to encourage regional defaults or case-by-case quantity? no (too much variation) text? no (use names if need to restrict) dates? (earliest date, etc) no binary? (images, etc) no - encourage case-by-case setting of maximum size Any others? Does that just mean the identifiers and names need restrictions? In that case I would say it's easy: Name - default 256 UUID - default 256 ID - default 35 How's that? Just add CAM or Schematron :-) Then add local restrictions on amounts, binary data and certain codes. (Again using CAM or Schematron, say). It's a start anyway. On 14/02/2008, David RR Webber (XML) <david@drrw.info> wrote: > Tobey, > > What you are seeing in the difference between the raw specification and the implementation - how it is applied in the field. > > An XSD schema (and by extension UBL) provides the roadmap for all possible > structure permutations that are valid according to that published schema. > > That's not the same as an exchange instance that will actually work with someones actual implementation system. > > That need is being addressed by the OASIS CAM templates work. We've developed some example subset templates and you can find downloads of those here: > http://sourceforge.net/project/shownotes.php?group_id=186271&release_id=482510 > > And the jCAM open source implementation tool - http://www.jcam.org.uk allows you to experiment with these. > > The idea being that people can pre-check their exchanges against both the documentation and run check that CAM provides - to ensure they meet those specialized requirements. > > Ultimately as you suggest - we'd like to have catalogues of these available for people to try and share. Right now we have the wiki for UBL and CAM available to start collecting and sharing those - but as with everything - more work needed to provide comprehensive resources... > > DW > > > > > -------- Original Message -------- > > Subject: RE: [ubl-dev] How big can the invoice number field be? > > From: "Tobey, Thomas N." <Thomas.Tobey@lfg.com> > > Date: Thu, February 14, 2008 10:17 am > > To: <ubl-dev@lists.oasis-open.org> > > > > > Jon et al, > > I see that the capability exists to restrict limits. Partner to partner. > > Let's say a vendor is building an application which outputs invoices: > > where do they go to find out how long they should allow their invoice > > > number to be? Certainly they could take a poll of their customers. Or, > > > through trial and error they could discover they made a mistake when > > their customers begin convulsing on their invoices, due no doubt to > > > legacy systems. Why not go to standards-setting organizations not only > > > to get what is possible, but also to get best practices or pitfalls > > associated with current state systems? > > > > > Shouldn't a standard that is published which allows you to do anything > > be coupled with information addressing the current state and the > > possible road to get to the ideal state? Now, I'm not saying that you > > should demote yourselves to writing user manuals. But for key fields, > > which drive the mechanics of the whole thing, at least some advice > > should be given. So you don't have to write a whole new limitations > > doctrine for all fields. But please let people know what is important to > > consider. > > > > > Maybe it is just common sense to keep an invoice number small. I can > > write up a list of reasons why a smaller invoice number is better. > > Should something be published somewhere or left to common sense? > > 1. You are requesting a payment, don't make it hard, stupid. > > 2. Companies are still doing manual data entry of invoices. More data > > means more data entry errors. > > 3. Identity fields are the "phone numbers" for the subject. Meaning: > > each time someone calls someone else to refer to an invoice, the second > > person has to type in the identity number. > > 4. Customer legacy systems still have limits on invoice numbers. > > 5. Paper checks are still printed, which may have space limitations for > > customers. > > > > > Ugh, I just read a little bit of who I'm talking to. Jon, one of the > > creators of XML? Several other illustrious bios. OK, I'm going to go > > ahead and slick send on this email. I'm sorry if I sound provincial... > > > > > -TNT > > > > > > -----Original Message----- > > From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] > > Sent: Wednesday, February 13, 2008 10:11 AM > > To: ubl-dev@lists.oasis-open.org > > Subject: Re: [ubl-dev] How big can the invoice number field be? > > > > [fulton.wilcox@coltsnecksolutions.com:] > > > > | Perhaps UBL "best practices" should define typical field lengths, > > | but not build hard edits into UBL itself. > > > > Or perhaps people could use the XSLT validation pass built into > > UBL 2.0 for this purpose. As we point out in Appendix E of the > > UBL 2.0 Standard, > > > > The validation framework provided in the val directory can be > > used to implement code list changes, define variant code lists > > to fit specific trading partner agreements, associate different > > versions of the same code list with different parts of the same > > UBL document, and even perform fairly sophisticated business > > rule checking, simply by building additional logic into the > > XSLT file that drives the second validation phase -- and > > without changing the standard UBL 2.0 schemas. Schematron-based > > techniques for creating a custom XSLT file to take the place of > > defaultCodeList.xsl are explained in the UBL Code List Value > > Validation Methodology, the latest draft of which is available > > from the UBL TC web site. Using these techniques, the business > > analyst can offload a large proportion of input filtering from > > the backend business application to a simpler input processing > > area. And, of course, additional XSLT scripts can be added to > > extract logical subtrees of incoming UBL documents for > > allocation to different downstream processes and to perform > > even more sophisticated front-end processing. > > > > (http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#d0e9684) > > > > The mechanism needed to impose field length restrictions and a > > whole lot more is already built into the UBL 2.0 framework; all > > you have to do is use it. > > > > If people want to see a predefined set of such rules provided in > > the next release (2.1, due out next year), that's easy, too -- if > > they will step up to doing the work of defining the rules and > > creating the requisite Schematron assertions. There's no end to > > the "best practices" we could build into the package this way; all > > that's needed are people willing to invest the effort. UBL is a > > volunteer initiative, and, as Ken Holman said, we're always open > > to participation. I'm sure that the UBL TC would be glad to > > create a team to work on this if people were interested enough to > > join the TC and sign up for it. > > > > Jon > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > > > > > > > > Notice of Confidentiality: **This E-mail and any of its attachments may contain > > Lincoln National Corporation proprietary information, which is privileged, confidential, > > or subject to copyright belonging to the Lincoln National Corporation family of > > companies. This E-mail is intended solely for the use of the individual or entity to > > which it is addressed. If you are not the intended recipient of this E-mail, you are > > hereby notified that any dissemination, distribution, copying, or action taken in > > relation to the contents of and attachments to this E-mail is strictly prohibited > > and may be unlawful. If you have received this E-mail in error, please notify the > > sender immediately and permanently delete the original and any copy of this E-mail > > and any printout. Thank You.** > > > > --------------------------------------------------------------------- > > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]