MHonArc v2.5.0b2 -->
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)
From: Tim McGrath <>
To: "G. Ken Holman" <>
Date: Wed, 25 Jan 2006 11:39:48 +0800
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:
> 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/
