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

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Chee-Kai / Fulton,

Thanks for opening up the view of the possible applications for
the use of binary parallels to XML here. We could view the
XML and the XML Schema (XSD) as the theory (essential as such)
and the binary as the practical. Another analogy might be to
view the XML/XSD as the score and the binary as the audible music
but the binary 'sings' not to the score but to an adaptation of
the score by its use of the ASN.1 equivalent of the XSD.

So we need to have the practice of composing the score, then
having it adapted, then reading the adaptation and turning it
into music; in other words, architecting the schemas in XML
Schema, turning those into ASN.1 (as UBL does) and using the
ASN.1 optionally to determine the content of binary messages
(for various reasons such as interoperability improved compres-
sion). Making this 'standard practice' seems to me to offer the
optimal (by current state of art) solution for messages, whether
for RIA or for modern equivalents to the traditional uses of
EDI or to whatever is just around the corner. It's looking good.

It seems to closely parallel the standard practises of coding
software quite nicely so it should be very easy for developers
and information architects to understand. First the text, then
the compilation to binary. Here we have first the message
composition and the message equivalent of the source code
which is kept for posterity and maintenance, then we have the
binary equivalent which is actually used at runtime.

All the best

Stephen Green


>>> Chin Chee-Kai <cheekai@SoftML.Net> 13/11/06 05:25:55 >>>
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