RE: [ubl-dev] UBL payload and client-server integration tools

["David RR Webber \(XML\)" <david@drrw.info>]

Fulton / Chin Chee-Kai,

We actually already have this functionality in UBL - the UID value.

This was defined during the original ebXML work and adopted by CCTS.

It consists of a character prefix + 6 digit numeric id.

E.g. UBL123456, UBL001022, etc

The exact purpose is to be able to label components uniquely; and
then ebXML registry supports this in the RIM - via both ExternalName
and LID (Logical ID) elements.  Therefore you can store BIEs in 
registry and label them with their UID as the LID - and then 
retrieve them and reference them directly accordingly.

Similarly in CAM templates we introduced the Registry lookup
section - to allow you to associate between the model (UBL) and
the instance XML / XSD - by using the UID value as the 
crosswalk.  This means that on-the-wire XML does not need to
change - while your template matches the semantics to the 
definitions in the UBL model.

DW
 


 -------- Original Message --------
Subject: RE: [ubl-dev] UBL payload and client-server integration tools
From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
Date: Mon, November 13, 2006 12:55 pm
To: 'Chin Chee-Kai' <cheekai@SoftML.Net>, 'Stephen Green'
<stephen_green@bristol-city.gov.uk>, ebxml-dev@lists.ebxml.org,
ubl-dev@lists.oasis-open.org

Chin Chee-Kai

Your "quick thought ...to assign a UBL-wide unique
ID to each and every BBIE, ABIE and ASBIE, using possibly a 16-bit
word and values ..."  is I believe is in the right direction. There is
an
inherent modularity to UBL that makes an RIA-friendly approach feasible.
In
effect, these become more marketable if also offered "a la carte" as
well as
in a holistic bundle. In an IPv6 world, perhaps they get their own
individual IP addresses.

One further point with respect to "light" is that it is extremely
difficult
to "buy" latency reduction. Internet 2.0 "mashups" (front end, often
client
side applications that depend in invoking multiple applications,
services
and databases) have very constrained response time budgets, so they must
be
built for speed. Indeed, many client-server applications of the 1990's
(which themselves often were "mashups") often had sluggish performance
because they were built for "richness" rather than speed.


Fulton Wilcox
Colts Neck Solutions LLC



-----Original Message-----
From: Chin Chee-Kai [mailto:cheekai@SoftML.Net] 
Sent: Monday, November 13, 2006 12:26 AM
To: fulton.wilcox@coltsnecksolutions.com; 'Stephen Green';
ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] UBL payload and client-server integration tools

At 06:58 PM 2006-11-09 -0500, Fulton Wilcox wrote:
>Stephan et al:
>
>What are the implications of fairing UBL into RIA architectures?
>.....
>The second is to consider use of RIA techniques within the more typical
>eBusiness server-to-server exchange of transactions. RIA calls are built
for
>speed and light touch on bandwidth, so the fit would be to highly
repetitive
>transactions - e.g., price checks, inventory availability checks,
>transportation scheduling, etc.
>                                        Fulton Wilcox
>                                        Colts Neck Solutions LLC

Very interesting thoughts about RIA & the "built for speed and light
touch" stuff.  I'm much delighted to hear about this conversation.
I don't know much about RIA stuff, but do think the "speed and light
touch" aspect is interesting to explore for UBL.

From UBL instances' perspective, this could either be viewed or
translated
as (A) an encoding problem, or (B) a translation problem.

One could use specifications from binary XML to do (A) with significant
reduction in textual bytes in the instance payload.  But I suspect
RIA is going for the really highly interactive sort of communication
environment and might need a more rudimentary (B) solution.  In a way,
while UBL TC produces schemas as normative output, there's no limitation
that the instances cannot be mapped and stored in another manner.

One quick thought that comes to mind is to assign a UBL-wide unique
ID to each and every BBIE, ABIE and ASBIE, using possibly a 16-bit
word and values being assigned authoritatively only through/by UBL TC.
Structural composition of the BIEs could be easily done through usual
header/trailer byte style, or header-fixed-length packets.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org