Re: [ubl-dev] Comments on UBL-NDR 2 Versioning

[Chin Chee-Kai <cheekai@SoftML.Net>]

At 12:03 AM 2006-11-13 -0600, david.lyon@preisshare.net wrote:
>Quoting Chin Chee-Kai <cheekai@SoftML.Net>:
>
>>At 10:24 PM 2006-11-12 +0100, Marc de Graauw wrote:
>>>The term 'compatibility' is not defined.
>>
>>A very point-blank note indeed.  When I attended the recent UBL TC meeting
>>in Singapore, there appeared to be general reluctance (myself included) to
>>tackle head on with this topic, together with other heavy-weight words like
>>"compliance", "interoperable", "customization".  And the worse is certainly
>>to try to talk about them all at once;
>
>Hi Chin,
>
>Pardon my uneducated question, I've probably missed something
>important but - why?

David,

It is probably going to sound terribly unfair to those who voiced their
thoughts during the TC if I were to just summarise everything into a short
email.  But I'm glad you've asked for clarification, as I think I've left
too gloomy a view towards the words CCICC (compatibility, conformance,
interoperability, compliance, customization).  I do ask that you interpret
what I explain here as just my perceptions and views and not a summary
or minute of the proceedings in TC meeting in Singapore.  Otherwise
TC might not let me attend meetings as observer anymore...

I should say the primary "reluctance" was due to the long hours that were
spent and would have been spent in the meetings to reach a state of
significant consensus regarding what CCICC, together, mean.  A simplistic
explanation is that everyone has his/her own definition of what "must be"
CCICC.  This leads to long time being spent to explain one's thought and
view, and to attempt to convince all others that theirs may be less fitting/
superior/appropriate/___(fill in the blank) than one's proposal.  A proposed
definition set must certainly be self-consistent within CCICC, ie. one must
insist that a proposed definition for, say, compatibility, must consistently
allow an independent definition of conformance, interoperability,
compliance and customisation.

We saw how Marc had proposed a version of "compatibility" from his
own needs and requirements.  If I were to ask you, you'd likely have no
difficulty giving your versions as well.  To be fair to TC members,
they have very clear idea of what CCICC mean, except that there are
many such views to sort out so that (1) definitions among CCICC itself
are self-consistent (one won't have to face the possibility of
meeting conformance yet not interoperable nor customisable, for example),
and (2) majority could agree that that proposed set of definitions
is acceptable for their purposes and requirements.

I've also suggested that a definition of these be "computable", that
for a given instance or set of instances, one could consistently reach
a conclusion as to whether they are conforming, complying with UBL rules,
interoperating, and so on.  If the definitions are too vague or wishy-washy
just to satisfy a quick completion of specification, it may allow too much
of variations subsequently as to lead to more complex software development
to accomodate various branches of development.

One other aspect I should point out is also that UBL TC's normative
output is the set of normative schemas.  Yet users in actual environments
care much more about instances CCICC during actual operations than schema
CCICC.  So it is possible to observe that definitions proposed by
end-users tend to focus on instance-oriented CCICC, while UBL TC
needs to simultaneously attend to schema CCICC.  Both requirements
are not necessarily separate and independent, but my own view is
that the somewhat slightly different motivations from both groups
would introduce more complications to an agreeable set of CCICC
definitions.

With all these considerations in mind, I think UBL TC is actually
wise in taking careful evaluations, re-visits, and probing more
debates before arriving at a practical and stable set of definitions
for CCICC.  It is a tribute that the Co-Chairs listen to various
opinions and not opt for hasty conclusions.

On the bright side (BTW I don't mean we're currently in the dark side),
I get the sense from the Singapore meeting that most of the ground work
for UBL schemas is complete, leaving the TC with more time to focus on
these important practical and implementation-oriented aspects of UBL.
So Marc's comment is certainly very timely.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/