MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ubl] Using CCs correctly (was Re: [ubl] Review of Two Diffs (Michael/Sue's and Stephen's))
Ok,
here is my 2-cent opinion:
Mark
is correct in pointing out the issues with the current UBL Library in relation
to applying CCTS and the missing CC�s.
Tim
is correct that there is a cooperation with UBL and TBG17, and this should work
in the way that UBL uses CCTS to build its library, it uses TBG17 SGP and
submission form to submit to TBG17, and TBG17 gives back the result which UBL
implements. If not, well I agree with Sue, that then there is not much point in
the exercise.
Michael is not correct in that the first draft ACC�s has been TBG
approved, but they hopefully will by Washington. For SGP this is also
true!
In
summary:
Could the current UBL Library be better in relation to compliance with
CCTS? - Yes!
Will
we soon have CC�s to work with? - Yes!
Will
TBG17 respond to the UBL submission? - Yes?
Will
UBL comply with the response and feedback? - That is left to be
seen!
But
one thing is for sure: There is no reason, no point, no resources and no way
that UBL should keep a separate track nor even begin to consider being a
full-time proprietary standards organisation in the area of data definitions,
maintenance, etc. There are more than enough of those.
Best Regards
Stig Korsgaard
M.Sc.E Standardisation Manager
Tel:
+45 3370 1083
Cell: +45
2725 9083
Mail:
stk@finansraadet.dk
Danish Bankers
Association
Amaliegade
7
DK-1256 Copenhagen K
Tel: 3370
1000
Fax:
3393 0260
mail@finansraadet.dk
www.finansraadet.dk
ouch, ouch -
I
agree with Tim that it's quite difficult to find the proper view and way.
Sometimes I feel that CCTS was made by many geniuses and then it has been
handed over to normal people, which have to do the diligence work to fill the
gaps these geniuses left.
The
CCs as of Bonn are TBG approved ones. Therefore more than a draft. But I do
not know whether this has to be considered as a UN Standard draft
already.
Hisano mentioned several times that he is mainly interested in semantic
interoperability, i.e. to use the same CCTS methodology. As far as I see Mark
mentions that UBL does not fully meet the CCTS methodology. He explained this
by describing at least two issues. This are issues where all the
other CCTS pilots I know have the same interpretation. [off record: Mark
is not the chief cook here. He just has the same
position.]
Additionally the different CCTS based projects came up with a lot
of detailed questions where they feel that CCTS is unclear or maybe wrong.
They want to fill the gaps I've mentioned above.
Considering the real need those guys expressed, we started a discussion
within the TBG and called the group ad hoc clarification. The
current result of these awful analyses can be found in the TBG17 Submission
and Procedure Document, which is an approved TBG document, I think. (Sue: is
this correct?) The discussions continue and I expect from the GEFEG
Berlin hosted meeting next week a further small step
forward.
Michael
BTW:
this English English is what I have to read several times in order to
understand it. My dear native speakers: PLEASE us international English;-).
You cannot expect that the rest of the World will be able to speak this fine
English today. Maybe the world can, when the major language is U.S.will be
Spanish, i.e. in 15 years from now.
ouch! i dont think anyone in UBL has a
desire for a different furrow - we just dont know what the proper one is.
as the UBL liaison to CEFACT, perhaps you can answer the
questions i put to Mark. How can we implement core components today,
for UBL 1.0 (or even UBL 1.1)? where is it we have not applied CCTS
semantic naming rules correctly?
my point to Mark is that this is not
going anywhere if no-one can say what UBL needs to do to "work
together with TBG17 to agree, prove, implement and pass on to the CCTS
development team the clarifications which are essential to ensure that we
can build and use a common Core Component Library." personally, i
thought UBL had done (and was still doing) this - but obviously you don't
agree.
I am not sure what you mean by "'throw their candidate CCs
over the wall' and then do not participate in the spirit and the work of the
follow-up harmonisation" - isn't that what the overlapping members and
liaisons between UBL and TBG17 should be doing? Has there been any formal
feedback or follow up from TBG17 to UBL? as far as i know the work
done by TBG17 is still within the CEFACT environment for comment and has not
been published to a wider audience*. so i find to hard to know how we
can "be taking the TBG17 clariifications and their draft library into
very serious consideration for UBL. "
Am i missing something
here? Does anyone else have an opinion on this? Sue's comment about
"giving wider international standardisation a try" should really be
to the whole TC and not me personally (i hope).
* I am aware
of some of the TBG17 work through seeing an excellent presentation by
Hisano Sugamata when I was in China at an ebXML Asia meeting last month -
but this was presented as very much a first draft and was said to be still
being debated within TBG17.
Sue Probert wrote:
Hi Tim
TBG17 is a collection of people exactly trying to 'do something
about this' and their number include several past and/or present UBL
library SC members who care passionately about working together,
under the only truly international business users forum that we have, to
try and solve this problem in a single, published unambiguous
way. This will not be trivial and it will not be
easy.
I humbly suggest that, in order to maximise all our world wide
efforts to achieve the holy grail of improved semantic interoperability,
we work together with TBG17 to agree, prove, implement and pass on to the
CCTS development team the clarifications which are essential to ensure
that we can build and use a common Core Component
Library.
This TBG17 work is progressing well with a number of useful
clarifications already available togethre with a draft library which is
certainly proving its worth with several user communities with which I am
either working or familiar.
How about UBL giving wider international standardisation a try,
Tim? TBG17 cannot succeed while submitters simply finish their work,
'throw their candidate CCs over the wall' and then do not participate in
the spirit and the work of the follow-up harmonisation. IMHO
we should now be taking the TBG17 clariifications and their draft
library into very serious consideration for UBL. BTW I do
not believe that UBL will be able to achieve its potential
impact if it continues to plough a separate CCTS
furrow.
regards
Sue
so what can we do about
it? where are the CCs we should be basing this on? we stated up
front that all unqualified BIEs in UBL would be candidate core components
and have submitted them to TBG17 on that basis.
I accept
that despite numerous reviews and discussions we did not always agree on
the use of qualifiers or terms, but as we have no consistent examples or
definitions in the CCTS we are feeling our way as to how these should be
used. pehaps you can help us?
MCRAWFORD@lmi.org wrote:
Tim,
* what do you mean by 'the library
of CCs'? - i am not aware there are any.
Exactly, thats the fundamental problem. Without
defining and basing all of your BIEs on CCs you are 1) non conformant
with CCTS and 2) unable to have the underlying structures that are key
to any harmonization and approval process.
* what do you mean by 'consistency in the use of qualifiers vs.
multi-worded object classes and property terms'? - i thought we
had introduced property term possessive nouns and nouns to try and deal
with this more formally than the CCTS itself.
First, the property term possessive nouns and nouns are 1)
not CCTS 2) confusing to the model, and 3) were not implemented
uniformly. Second, there appear to be zero qualifiers used for the
object classes - rather a host of unqualified object classes have been
defined for the reusables.
Mark
Mark R. Crawford
Senior
Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS,
RosettaNet Representative
Vice Chair - OASIS UBL TC & Chair
Naming and Design Rules Subcommittee
Chair - UN/CEFACT XML Syntax
Working Group
Editor - UN/CEFACT Core
Components
LMI Government
Consulting
2000 Corporate
Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810
Wireless
The opportunity to make a difference has
never been greater.
www.lmi.org
your comment is clear in that you
obviously see a disconnect but i am not sure how to deal with this
without tangible examples...
for example:
MCRAWFORD@lmi.org wrote:
Tim,
the comments appear pretty clear to me. You did
not base the library on CCs - hence the BIEs are a hodgepodge of
objects with no real relationships that are fully
harmonizable. The library has no consistency in the use of
qualifiers vs multi worded object classes and property terms hence
the relationships are unclear at best.
Mark
You have made this statement before
but I have not seen examples of what you mean by this.
Perhaps you could explain where we have gone wrong and what
we should be doing using UBL1.1 BIEs? It is hard to correct
something if we don't know what we are aiming for.
MCRAWFORD@lmi.org wrote:
One of the fundamental problems with the library
is the Lack of consistently applied object qualifiers. This
makes any harmonization extremely difficult if not impossible,
and leads to a questionable conformance to ccts. The use of
property terms and qualifiers is equally problematic in the way
we have done it. Until and unless we begin to base our Bies on
CCs we will have a disconnected inconsistant library that
manifests itself in the form of inconsistent schema.
Mark
Crawford
Research Fellow - LMI XML Lead
W3C Advisory
Committee, OASIS, RosettaNet Representative
Vice Chair -
OASIS UBL TC & Chair Naming and Design Rules
Subcommittee
Chair - UN/CEFACT XML Syntax Working
Group
Editor - UN/CEFACT Core
Components
______
Logistics Management Institute
2000
Corporate Ridge, McLean, VA 22102-7805
(703)
917-7177 Fax (703) 917-7481
Wireless (703)
655-4810
mcrawford@lmi.org
http://www.lmi.org
"Opportunity
is what you make of
it"
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160