Re: [ubl-dev] How big can the invoice number field be?

["Stephen Green" <stephengreenubl@gmail.com>]

Jon wrote:
> ...  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.

Count me in Jon. If UBL would be willing to publish an optional
set of schematron schemas restricting datatype lengths to EDI
defaults (with option to locally overide/edit defaults) and give it
some weight so as to help interoperability, along the lines of the
codelists, I'd be glad to participate. It would be good if someone,
perhaps on this list, would point to the appropriate values though
(Fulton W?, Tim M?, Andrew S?,...? ). This would be very cool :-)


On 13/02/2008, jon.bosak@sun.com <jon.bosak@sun.com> wrote:
> [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
>
>


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