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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]