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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: SV: SV: [ubl-dev] UBL Basics.. try "Productivity"....


Bryan, 

I'm on the pragmatic practice v theory train today. 

Fact and theory - Wikiquote    "In theory, there is no difference
between theory and practice. But, in practice, there is." ~ Jan L. A.
van de Snepscheut...
en.wikiquote.org/wiki/Theory
 
In theory the CAM work has been focused on providing the bridge - the
better mouse trap here - that allows you to use a broad variety of
on-the-wire rendering formats - while still being able to equate each
elemental Lego brick back to its CCTS BIE and hence further better
interoperability and information consistency.

However for v1.1 CAM - we've had to go to market with a pragmatic
compromise.  The world (it's not just Ken!!) is XSD-centric.  And they
also use java tools like XMLBeans - so they have no use for CCTS/BIEs
and such - they want that uniform XSD to drive their java tools - and
they don't care what else people are trying to introduce.

: -(

It's the engineers view of XML and eBusiness exchanges - not the
information modellers - that dominates here.

CAM at least is a halfway house.  By having more engineers start to use
technologies like CAM - to supplement their XSD - and document the
interchange contextual specifics - then we can get the two halves
coming closer together - and sharing benefits.

CAM provides the modellers the means to handle the information exchanges
at a more rule driven and abstract level than raw XSD.  Meanwhile CAM
provides the engineers with nifty runtime tools that make their job
easier - helps partners build better XML to send them - causing their
XMLBeans to fail less often - and keeps data analysts happy - because
it provides great documentation they can read and verify.

We still have more work to do on better registry interfacing - storing
BIEs in registry - and enabling tools like CAM to then do more via
standardized definitions held in registry and being able to automate
mapping across wire formats.

In theory a CAM template should be able to accept EDI, "simple-XML",
conformant-UBL all equally - and apply a consistent set of business
logic checks and rules - to enable the interactions.

My mantra has always been "transformation at point of use" - being able
to present the correct format contextually and thereby minimizing the
impacts across the whole.

In practice - we still have some more work to do on all that! But at
least we are making progress in the right direction. ; -)

Cheers, DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

  

-------- Original Message --------
Subject: SV: SV: [ubl-dev] UBL Basics.. try "Productivity"....
From: "Bryan  Rasmussen" <BRS@itst.dk>
Date: Mon, February 12, 2007 9:07 am
To: "Stephen Green" <stephen.green@bristol.gov.uk>,
<ubl-dev@lists.oasis-open.org>

I'm pretty sure I would want to call it a serialization of the UBL
model.
such as this is a namespace free serialization of the UBL model, in
compliance with CCTS customization rules. 
 

Cheers,
Bryan Rasmussen

-----Oprindelig meddelelse-----
Fra: Stephen Green [mailto:stephen.green@bristol.gov.uk]
Sendt: 12. februar 2007 14:56
Til: ubl-dev@lists.oasis-open.org
Emne: Re: SV: [ubl-dev] UBL Basics.. try "Productivity"....


No, that's not right because the context is already there
in the BIEs (as distinct from the CCs). Nor is it a recontextualisation
since the BIEs are unchanged. It is certainly in the broader sense
an implementation. And it is one which CCTS provides for when
UBL is itself seen as an implementation of CCTS - in which case
UBL should provide for my schema as a kind of implementation
of a CCTS-compliant language.





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