OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: RE: Oooh - Ouch! Is it necessarily the Truth if it Hurts?

Re:Perhaps Stuart Campbell would like to shed some more light on this?

***David, since you asked (but from a personal - not DAMSAD - perspective

The ebXML community have decided that the Core Components papers meet
certain requirements - sufficient enough to be technical reports but
insufficient to be specifications.  This suggests they are perhaps of
greater quality/status than many thought they may have been but not as high
status as many would have liked.

Most of us would be naive to think that there is not more work to do on
ebXML and the degree of activity is substantially more in core components
than in TRP for instance.  Many others have also seen this - eg xCBL
initiative, observations from TA? group (one member?) etc etc and i think
the DAMSAD report says essentially this but in a 'hard' way.

With regards to Williams quotes..
   ...our datatyping CWA has not had any influence on the development
   of ebXML,
***its a fact but thats life

   which insists on using a limited set of "representation
   types" based on existing EDI practices which are not formally
   defined, rather than adopting formal definitions of the type
   supplied in XML Schemas as recommended by the CWA...
***I think the issue is not so much that they are based upon W3C schemas but
more the fact there has:
a)been similar consideration by w3c and you might have thought that the two
groups would have come to similar conclusions even if one went a little
further and XMLified them - ie the fact that there are different schema
representation types has nothing really to do with XML but is solely do with
the types that were considered and selected (and then XMLified).
b)been no formal definition of these types

 ...I had originally expected the ebXML initiative to provide a
   sufficiently understandable set of rules.... The poor quality of
   the ebXML core components deliverables, however, precludes its
   content from direct use in a CWA.
***As far as i can tell it is only the naming conventions which looks like a
specification and as such in terms of specs this statement is right - eg i
couldn't see any of these CC docs being accepted as a CEN or ISO standard in
its current condition - but then again i never could fathom how the open-edi
spec became one either :-).  However, they are a great input to further

   The confusion as to how and
   when ebXML core component libraries will be created and managed,
   how these will differ from ebXML Business Libraries, and how users
   will access such libraries, makes it impossible to provide coherent
   guidance on the management of semantics related to ebXML, let alone
   advice of a more generic nature....
***I certainly agree with this as do many other comments ive seen from those
inside and outside of ebXML.  We have a set of technical reports in CC but
as to how implementers and users fit together and fill in the lines between
their overview 'box diagram' (cc overview doc) is still an 'interesting area
for clarification'.  I look forward to your book david!

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC