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] Code list value validation methodology (version 0.3)


Very occasionally someone produces a piece of work that establishes a 
milestone, a reference that we can use to focus our ideas and build 
upon.  Ken's proposal is such a piece of work.

I think he has succinctly defined the issues, documented appropriate 
solutions and provided meaningful examples.  I congratulate Ken and 
thank him for encapsulating so much of the past few years work into one 
place.  This paper should be the basis for all our future code list 
work.  I support it entirely.

In fact, i suspect it also provides the seed for a broader 
contextualization approach.

Ken, I have a few comments but they are not to detract from what is 
written, just some thoughts that may help relate these ideas to previous 
code list validation approaches.

In section 3.2 you perfectly describe how partners may wish to constrain 
sets of values (such as USD and CAD), but we should also recognize that 
extending the sets is a requirement too.  Sometimes they just have to 
add a value that isn't in the set, as when new currency codes are issued 
that have not made it to the 'standard set'.  Basically it is safer to 
assume that no codelist is stable and no set of values is fixed over 
time.  I believe your approach would work with this requirement as well.

In section 5.3 (para. 2) you say "order invoice'.  Did you mean the 
Order-to-Invoice procurement scenario or is it a typo?

The last paragraph of section 5.3 decribes the XML  equivalent of what 
EDI calls an Implementation Guide, Message Implementation Guide (or 
MIG).  It might make sense to some of us if you say this.

Section 6.1 reads to me like some of the material in the OASIS Context 
Assembly Mechansim (CAM).  Is anyone able to say how CAM relates to this 
approach?

In Section 7.1 we should note that the names of UBL codelist metadata 
(attributes) have changed.  I think your examples are based on UBL 2.0 
attribute names and anyone looking at UBL 1.0 may wonder.




G. Ken Holman wrote:

> Happy holidays, everyone!
>
> I've just uploaded a complete draft of my proposed code list value 
> validation methodology first discussed at the Ottawa face-to-face in 
> August (sorry for the delay), complete with a running example for a 
> Windows test environment:
>
> http://www.oasis-open.org/committees/download.php/16054/UBL-codelist-methodology-0.3.zip 
>
>
> All of the support files will already work in a Linux environment, 
> what I haven't done yet is create a Linux test environment to 
> illustrate the support files working.
>
> I've already thought of a new feature so I've added a chapter at the 
> end indicating some future changes.  But other than those, I think the 
> document is complete, and I need your feedback to know if you think 
> the document is complete as presented or if it needs to be beefed up 
> because I've made too many assumptions.  Also if you think I'm missing 
> the point or there is a better way to achieve what I'm trying to achieve.
>
> Please take the time to review these ideas over the next 6 to 8 weeks, 
> posting your comments at any time.  Then I'll work on a revision to 
> incorporate my new idea and any considered feedback that I find on the 
> TC list.  I'll also send this to the UBL Dev list for comment.
>
> I've tried to present this methodology in such a way that UBL is used 
> as an example of the methodology working, so that other projects can 
> point to the process and support files for their own use.
>
> Have a happy new year, and good luck at the Manhattan meeting!
>
> . . . . . . . . . . . Ken
>
> p.s. I have run out of time to upload the XML-based 
> authoring/publishing environment I used for this UBL specification ... 
> it is on my action list and I will present this (again in about 8 
> weeks) for other members to consider using when writing up 
> specifications.  It piggy-backs on the DocBook stylesheet for the 
> DocBook OASIS Committee Specification.
>
> -- 
> Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://www.docengineering.com/




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