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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types


Maybe there is a bit of a conflict here between UBL doing
what paper does and UBL doing what EDI does. Which is the
priority for UBL? EDI would seem to favour the fixed-width
limitations analogous to restricting string lengths, etc.

I tend to agree with the document-centric view which Ken is
espousing. Paper invoices don't disallow more than three
decimal places of a limit of invoice line description (except
by arbitrary document data input processes rather than by
the very nature of the concept of what in business terms
constitutes a printed invoice). How an input clerk adds that
data from the document to the finance system doesn't depend
on agreements about what an invoice should contain; not
typically in my experience (quite narrow experience). It
might be agreed that invoices have to be in EUR but that
* probably * (there may be exceptions) doesn't mean that an
invoice in USD isn't a legally binding invoice.

However it is entirely feasible that an invoice in USD will
have to be sent back to the sender because a trading agreement
with the supplier required invoices to be made out in EUR only.
Likewise an invoice with an invalid Order Reference might be
returnable as contrary to business terms. Typically the
application limitations will lead to business terms allowing
business to work smoothly. Software facilities are just as
much a reason to specify business terms as banking facilities.
I think there should be a way to express such requirements in a
way that is machine readable and/or unambiguous, such as with
the Codelist Methodology. Hence the possibility of a need to
cater for other datatypes in something like the codelist context
association files. Maybe. Maybe a bit later though?

All the best

Steve




Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:

> At 2006-05-08 12:10 -0600, stephen.green@systml.co.uk wrote:
>> Following the conversations prompted by Joseph Chiusano I've an idea
>> UBL might need, besides its Codelist Methodology, a general methodology
>> for at least restricting datatypes and maybe extending them in some
>> cases.
>
> I'm not yet convinced, but I don't want to stop the debate and I may 
> yet be swayed.
>
>> I was thinking that it is possible with UBL to extend and restrict
>> enumerated codelists without it being called customisation. Yet to do
>> this with other datatypes it might be necessary at the present to call
>> it customisation. How about in future adding to the Codelist Methodology
>> a way to do the same or similar (as one can for codelists) with other
>> datatypes.
>
> But why is it being done in the first place?  It seems to me to be 
> accommodating vendors and not users, creating an artificial limit to 
> accommodate programs rather than letting business use what they need 
> and having the program accommodate the users.
>
>> A trading agreement which limits the currencies used to just USD might
>> be such that a document with other currencies included isn't regarded
>> as valid.
>
> From a business perspective, yes.
>
>> The codelist methodology allows for this. We seem to need a
>> way to apply such criteria to datatypes other than codes.
>
> Again I'm interested to know why ... I know what you are asking, but 
> not the justification to limit some business users' needs for, say, 
> long description fields.
>
>> In some cases
>> it might be that an instance is invalid with Text types having an over
>> long string value. In other cases it might be that they aren't invalid but
>> an non-fatal exception is raised (the latter being more along the lines
>> of the SBS subsetting methodology).
>
> But is this being done because of poor program design that 
> arbitrarily limits the string values rather than accommodating 
> business needs for long strings?  I thought I got away from string 
> limits when I got away from programming in COBOL and RPG II ... those 
> were the last programming languages I used where records were mapped 
> to fixed-length fields.
>
> I think fixed-length limitations are anathema to *document-oriented* 
> processing and is too *record-oriented*.
>
>> Maybe the latter could be called 'UBL subsetting' and the former 'UBL
>> profiling' (the codelist methodology seeming to suggest 'UBL profiling'
>> for codelists).
>
> Why not just "business rules" or "application rules"?
>
> Though I'm still not convinced they are justified.  If a business 
> user finds the XML vocabulary suits their needs but the application 
> software doesn't, they could look for application software that does. 
>  If they, then, decide that they cannot for whatever reason change 
> the application, then they have a business rule for limiting it, say, 
> as a non-fatal error message.
>
> Jon has already requested the supplementing of code list constraint 
> checking with trading partner business rules in a single Schematron 
> pass, so I'm building into the 0.5 methodology a way to include 
> arbitrary Schematron rules in addition to synthesized Schematron 
> rules so that trading partners can exchange and point to their own 
> supplemental Schematron expressions that have constraints to be 
> included with, but considered higher priority, than the synthesized 
> Schematron rules.  BTW, I haven't figured the most elegant way to do 
> this yet, but I'm working on it.
>
> But, again, string limitations are just not (to me) 
> document-oriented.  If a business user needs to express their line 
> item description in 1001 characters, then using 1000 characters must 
> not have been appropriate.
>
> . . . . . . . . . . . . . Ken
>
> --
> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
> Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
> Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
> Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
> World-wide on-site corporate, govt. & user group XML/XSL training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing 
> the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]