[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Code List Value Validation
Fulton, I think we are agreeing (so I'll stop arguing :-). The accomodtion in the standard schema for a business transaction is only where there is *no standard* enumerated list that can or should be offered (that is, the values are entirely the business of the TPs involved and UBL, or any other standards body cannot predict their values, only provide a standard placeholder). And yes, I too integrate with some organisations who are *important* enough commercially to over-ride any standards practice other than their own. Thanks for benefit of your experience on this one. Keep it coming :-) Fraser. On 08/04/06, Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> wrote: > In accommodating the need for "non-standardization", I suggest that there > are two conditions to avoid. > > 1. Avoid helping people make "stealth" exceptions, in which everything in > the UBL transaction looks "standard," even though it is not. > > As a hypothetical example, someone who trades within the U.S. and who has an > organizational focus on the New England states of the U.S., might decide to > invent and use NE as a country code. This example is weird, but I've seen > weirder. > > Stealth implementation of this sort of exception is a problem, because even > though "trading partners" agree and understand what they are doing, those > "partners" often are far removed from the broader interests of their own > companies, let alone third party interests - the tax people, the 3rd party > logistics provider, etc. > > 2. Avoid the "crowding out" of standard data by non-standard data. > > If trading parties can easily stuff non-standard data where the spec calls > for standard list entries, that preempts the inclusion of available standard > data. If as shown in my example the person wants to include "NE" somewhere, > what UBL offers to facilitate that inclusion should not preempt the use of > the actual country code. > > At some point, a standards group has to say "this far and no further." I am > not sure that what is being proposed in fact creates either stealth > situations or crowding out, so I offer these as operating principles rather > that specific feedback. > > Note that I am not indifferent to the need to sometimes violate standards. > In the interest of doing business with some very distinguished global > companies with some very undistinguished data practices, I personally have > had to contribute to the art of "misuse of standard transactions." On the > other hand, what is situationally necessary should not inadvertently be > blessed as a valid part of the standard. > > Regards, > > Fulton Wilcox > Colts Neck Solutions LLC > > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Saturday, April 08, 2006 5:23 AM > To: fulton.wilcox@coltsnecksolutions.com > Cc: ubl-dev@lists.oasis-open.org > Subject: Re: [ubl-dev] Code List Value Validation > > > On the other hand, a "nonstandard" standard code list is an > interoperability > > issue > > Well gosh, standard is a difficult term since it is so dependant on > scope. I can have a 'standard' approach to exchanging data with a > particular set of trading partners, and I can have a 'standard' way of > exchanging certain data with everyone that I have dealings with, but I > take your point. > > IMO the suggested approach in UBL in no way proposes that standards > which are regarded as global specifications of well > understood/accepted semantics should be usurped by private > declarations of the same concept but with differing value-sets. > > Indeed the draft proposal is at pains to identify enumerations which > are established and maintained by a recognised body (of course what is > regardard as an acceptable 'standards body' can differ widely from > industry sector to sector) and suggests that such 'code lists' are > only extensible through the mechanisms offered by that 'custodian' > body. For example, UN/CEFACT lists used by UBL fall into this camp. > > At the same time though, the proposal recognises that the data model > should reflect the required business semantics of the exchange between > the communicating parties and that no standard should operate as a > constraint over those business expectations. > > In my experience, it is certainly the case that data exchanges between > trading partners often consist of largely standards based data models, > but also include aspects which are private to a specific > relationships. The UBL proposal recognises that some codified lists > are entirely private, and as such are the responsibility of the TPs to > define, and others where there may be a definition of some subset(s) > which apply to particular [common] use cases, but which also may be > extended/restricted for local purposes. > > I entirely agree with your concerns about interoperability, but at the > same time, from the actual practicalities of doing integration > projects I can accept that there is a tension between the business > operational model and the ideal of a common data standard. > > The conclusion that I am currently considering at is that it is not > commercially viable (given the complexity of all of the trading > relationships that organisations maintain) to have the operational > business model constrained by one or more external data standards > bodies. At the same time, it is desirable from a data consistency, > interop, business 'reach', and technical reuability perspective, that > every connection to a trading partner isn't a 1:1, point-to-point, > unique exercise. I do not want my organisation to become a 'standards > body' (although actually there are some advantages to this - think > WallMart ;-) but I don't expect anyone else to dictate (or have undue > influence over) the way the business wants to operate either > internally or how it manages its relationships with trading partners. > Finding the 'sweet spot' by balancing these factors is what I am > seeking. > > I could [re]-open the perma-thread about whether extensibility in > schema is acceptable and whether it damages standards based interop, > but I won't go there for now :-) > > >it would seem preferable to alter the schemas to have private codes > existence > > explicitly recognized > > Agreed. As I undestand it UBL schema reference external code lists > using a standard structure which provides meta-data to identify the > specific resource E.g :- > > <xsd:complexType name="CodeType"> > ... > <xsd:simpleContent> > <xsd:extension base="xsd:normalizedString"> > <xsd:attribute name="listID" type="xsd:normalizedString" use="optional"/> > <xsd:attribute name="listAgencyID" > type="xsd:normalizedString"use="optional"/> > <xsd:attribute name="listAgencyName" type="xsd:string" use="optional"/> > <xsd:attribute name="listName" type="xsd:string" use="optional"/> > <xsd:attribute name="listVersionID" > type="xsd:normalizedString"use="optional"/> > <xsd:attribute name="name" type="xsd:string" use="optional"/> > <xsd:attribute name="languageID" type="xsd:language" use="optional"/> > <xsd:attribute name="listURI" type="xsd:anyURI" use="optional"/> > <xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional"/> > </xsd:extension> > </xsd:simpleContent> > > </xsd:complexType> > > Fraser. > > On 07/04/06, Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> wrote: > > All: > > > > I am not quite sure of the practical implications of what is being agreed > or > > suggested, so below is what may be an expression of concern. > > > > Some time ago (New Orleans?), Anthony Coates gave a presentation that used > > as an example the "codeset" for the days of the week (Sunday through > > Saturday, variously expressed in upper and lower case, English or French, > > sequential numbers, etc). Such a codeset is "standard" or at least > "closed" > > except for representational details. I presume that the current discussion > > does not have to do with managing mere like-for-like changes in > > representation. > > > > Instead, the "extensions" now being discussed would seem to fall into two > > cases - 1) adding finer granularity and 2) complete add-on's. Greater > > granularity would be, say, dividing "Friday" into Fridaymorning and > > Fridayafternoon. An add-on would be moving to an eight day calendar (e.g., > > adding "Newday" between Saturday and Sunday to create three-day > weekends.). > > > > Do these exemplify the two problems being discussed? > > > > With respect to the solution, the various implementation options > > (genericode, CAM) seem to provide the means to make such extensions > > selectively coexist with UBL schemas, which I presume is good in an > > introspective sort of way. > > > > On the other hand, a "nonstandard" standard code list is an > interoperability > > issue and, perhaps, an oxymoron. From an ERP to ERP data synchronization > > perspective, if certain trading partners are to use what amount to private > > codes, it would seem preferable to alter the schemas to have private codes > > existence explicitly recognized and, one can hope, for the transactions > > exchanged also to include applicable the standard codes or an explicit > "not > > available." > > > > I may be mis-characterizing either the problem being solved or the > solution > > being proposed, but I did want to raise a concern. > > > > > > Regards, > > > > Fulton > > Wilcox > > Colts Neck > > Solutions LLC > > > > > > > > > > > > -----Original Message----- > > From: David RR Webber (XML) [mailto:david@drrw.info] > > Sent: Friday, April 07, 2006 11:22 AM > > To: Stephen Green > > Cc: ubl-dev@lists.oasis-open.org > > Subject: RE: [ubl-dev] Code List Value Validation > > > > Stephen, > > > > Understood. > > > > We'd be happy to work on some small samples to test this out and refine > > the specification accordingly. > > > > Thanks, DW > > > > > > > > -------- Original Message -------- > > Subject: RE: [ubl-dev] Code List Value Validation > > From: "Stephen Green" <stephen_green@bristol-city.gov.uk> > > Date: Fri, April 07, 2006 9:25 am > > To: <ubl-dev@lists.oasis-open.org> > > > > Something UBL users need is the granularity to say that a particular > > codelist > > is used for a code when it appears say in the InvoiceLine but not when > > it > > appears in the main body of the document, or more precisely that, say, > > BuyerParty/SomeCurrencyCode includes USD and EUR whereas > > SellerParty/SomeCurrencyCode only includes CAD > > This is the sort of use case the UBL codelist methodology caters for. > > > > Maybe CAM could take on board the UBL codelist declarative syntax to > > align the two methodologies. > > > > All the best > > > > Stephen Green > > > > > > >>> "David RR Webber (XML)" <david@drrw.info> 07/04/06 13:50:07 >>> > > Fraser, > > > > There are two levels to this - the specification and the implementation. > > > > I'd be interested in your thoughts on the lookup() functionality in the > > OASIS CAM system and the jCAM implementation that supports the use of > > codelists over XML transactions. > > > > The current implementation has baseline functionality for managing and > > using codelists: > > > > http://www.jcam.org.uk > > > > Key from the implementers stance is being able to cover off the > > following: > > > > 1) Declarative rule values in XML > > 2) Lookups to SQL table code values > > 3) Simple inline code alignment (e.g. 1,2,3,4,5 | A,B,C,D,E) > > 4) Associative code lookups - if A then X,F,J ; if B then X,F etc > > 5) Callout to Java routines - permits extended calculated lists via > > multiple > > 6) Versioning and local extension values > > 7) Potential for referencing codelists stored in shared registry service > > > > Thanks, DW > > Chair - OASIS CAM TC. > > > > -------- Original Message -------- > > Subject: [ubl-dev] Code List Value Validation > > From: "Fraser Goffin" <goffinf@googlemail.com> > > Date: Fri, April 07, 2006 8:09 am > > To: "G. Ken Holman" <gkholman@cranesoftwrights.com> > > Cc: abcoates@idmm.co.uk, xml-dev@lists.xml.org, > > ubl-dev@lists.oasis-open.org > > > > Ken, > > > > its been a while since I have had a chance to catch up, so hi. > > > > I have been re-reading your UBL Code List Value Validation Methodology > > (v0.4) > > again while I've had a few days off (I know I need to get out more :-), > > a few questions if I may be so bold :- > > > > 1. How has this work been received in UBL. Is it proceeding as planned. > > Do > > you think there will be any statement on adoption of this methodology > > any > > time soon ? > > > > 2. A genericode file contains ONE code list at ONE version right ?? > > > > 3. In the doc you state that when an enumeration appears WITHIN a > > schema, > > TPs may ligitimately operate a subset since all values are valid in the > > full > > set, but they may not add new values. Am I correct in assuming that the > > same > > is true for a code list which is defined by a standards organisation > > (not > > UBL) but which is NOT embedded within schema ? > > > > As you know in my situation we operate code-lists than are defined by a > > standards body and in most cases want to use them in all situations > > where > > there are equivalent semantics (including internal app integration) > > rather > > than create alternative bespoke lists. > > > > Problem is, we do sometimes want/need to extend these lists often to > > provide > > higher fidelity mapping to our operational systems. Another example > > might be > > where a code identifies some high level semantic, but we want to be able > > to > > create a bunch of 'sub' codes to provide a more granular view - > > accepting > > that in 2-way translation there will be data loss. Lobbying the > > standards > > body and getting a timely change/addition can be problematic ? - > > anyway - > > I digress > > > > 4a. For code lists where there is no established [complete and/or > > definative] standard or where the semantics and values are TP > > relationship > > specific, the set of permissible values can be extended and/or > > restricted > > from an offered base set (if available - using your > > DocumentStatusCodeCodeType example) or the participating organisations > > can > > agree the set of values (and presumably the list ID to be used in XML > > instances). Is this correct ? > > > > 4b. If I have many TPs and each has a slightly different relationship, > > might > > this cause me to need a separate genericode file for EACH code list that > > differs, however slightly, from another ?. Is there a suggested low > > maintenance approach to this problem ? > > > > 4c. Similarly to (4b.), if a custom code list is shared across service > > contracts for multiple TP relationships, but a need arises to create a > > new > > version with [say] some values added or removed, and we need to be able > > to > > operate both versions concurrently for some period of time, does this > > require a complete re-statement of the new code list (in a new .gc file) > > with a new version number even if the difference is ONE codified value > > (added/deleted/changed) amongst a set of 10,000 values ? > > > > This also means that the implementation will repeat a lot of code. I > > guess I > > am wondering whether there is/should be a way of expressing a 'delta' of > > values ? > > > > 5. Continuing the theme of (4), we have some code lists which are both > > highly volatile (values added and deleted (rarely changed) every month) > > and > > are very large (e.g. > 50000 entries). An example is Vehicle Make/Model. > > Do > > you think this approach is suitable for this type of reference data > > (multiple 'active' versions, large number of values) ? > > > > 6. Can you explain the difference between the UBL 'CodeType' and > > 'IdentifierType' in terms of what circumstances you would use either ? > > > > If a schema identifies the ListID, but we want to use a different one > > (to > > employ as 'richer set' of values) , how would an industry standard > > schema > > accomodate this possibility such that the schema remains a standard and > > unchanged definition of the structural constraints (is this the > > CodeType/IdentifierType approach) ? > > > > 7. Do you think that a skeleton context association file could be > > auto-generated ? > > > > 8. Changing tack slightly. I am interested in using genericode files for > > a > > number of purposes including, value-based validation, UI generation > > (e,g, to > > populate UI controls such as list boxes), transcoding between > > application > > specific codes. It would appear from the genericode materials that this > > would be feasible, do you agree ? :- > > > > Std Code Std Desc Appl'n A Equiv Appl'n B Equiv UI Text > > (key) (key) (key) > > > > abc Std Widget def > > ghi Part No 3321-7 (small widget) > > > > 9. What is the suggested approach to deal with deprecated code values. > > Is > > this considered as a versioning issue both for standards based > > code-lists > > (embedded in schema or not) and custom code lists ? Should code lists > > include validity date/time values or other 'active/deprecated' > > indicators ? > > > > 10. Caller assertion of list version. If there is no matching version is > > it > > best to flag the validation failure (and possibly reject the message) - > > that > > is, 'trust' the caller assertion, or validate against the un-vesioned > > complete list (similar point to the one we discussed earlier about > > whether > > to to an xsi:schemaLocation attribute value) ? > > > > 11. Devils advocate: Whats the difference in having to distribute the > > latest > > .gc file versus having to use the latest XSD with updated embedded enums > > ? > > (Ok, I think I know the answer to this one, but it would be good to have > > a > > quote from 'championing' designer, for the benefit of my peer group and > > sceptical and untrusting bosses :-) > > > > Cheers > > > > Fraser. > > > > Anthony: So that you are aware, I am attempting to stimulate interest in > > the > > use of genericode within the organisation that I work with (a large UK > > financial services company) from a number of potential perspectives. One > > of > > these is value-based validation, hence discussions with Ken i.r.o his > > work > > with UBL, but also for a more broadly accessible resource for reference > > data > > used for a variety of purposes such as UI generation, transcoding, etc.. > > > > > > > > --------------------------------------------------------------------- > > 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/ > > > > > > --------------------------------------------------------------------- > > 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/ > > > > > > --------------------------------------------------------------------- > > 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/ > > > > > > --------------------------------------------------------------------- > > 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/ > > > > > > --------------------------------------------------------------------- > 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]