MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [ubl] Using CCs correctly (was Re: [ubl] Review of Two Diffs (Michael/Sue's and Stephen's))
I'd
like to add a further point to this pre-Copenhagen discussion: If we do not
restrict the reuse of reusable aggregates (ABIE) - where appropriate - we will
have huge documents, and users will have the same problems they already have
with the application of standards like RNet or oagi.
It's
very difficult for an user to figure out which of the 500000 to
700000 document elements are the right ones to map his 30-40 elements to. In
other words, the CCTS methodology prevents to build data church yards.
Imho
this is one of the big advantages of CCTS to combine redundancy free data
definitions and structures with context related
restrictions.
This
requires underlying ABIE or CC, what we do not yet have
everywhere.
I
would not consider this as a problem, as long as UBL just wants do develop a
simple data set just for simple documents. But what I see is, that people come
up with complex documents and complicated requirements. This will undoubtfully
lead to the extension of existing ABIE in reusable and to an useless extension
of ALL documents which use the aggregates of the reusable library - except we
restrict the inherited extensions where they are not to be
used!
This
also asks for a change log in the ss (I've just learned from Anne's issue list
that this is an abbreviation) referring to not yet fully existing formalized
DMRs. Thus we can maintain data and DMRs in a master and do not have to have
them in the schemas.
I seem
to remember that somebody asked whether UBL wants to become a standard
organization or so. Maybe the above mentioned questions are exactly among those
a standard organisation has to deal with.
Best
regards,
Michael Dill
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