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

["David RR Webber \(XML\)" <david@drrw.info>]

Jon,

There is the difference between theory and practice.

Alot faster and easier to use jCAM to do it - no coding required - you don't need to know xslt or schematron - just point your UBL sample XML instance at the Eclipse editor tool - click down to the element you want to check in the structure viewer, click add rule - pick setlength() -  type length range - 1-25 or whatever number you need, Save template - done.

And it will even generate user friendly HTML documentation right out of the box - no extra work needed.

Conceptually the xsd / xslt / schematron approach equates to CAM - but why do three things when you can do just one?!?

Time for UBL to start gaining the advantages that the CAM standard offers...

DW



> -------- Original Message --------
> Subject: Re: [ubl-dev] How big can the invoice number field be?
> From: jon.bosak@sun.com
> Date: Wed, February 13, 2008 10:10 am
> To: ubl-dev@lists.oasis-open.org
> 
> [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