[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?
[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]