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

[Sacha Schlegel <sacha@schlegel.li>]

Hi David

Have you seen an Open Source Javascript XML Digital Signature toolkit,
yet? ... to client side sign a dom or ubl instance?

There are some regular encryption algorithms implemented in Javascript
but not yet XML Digital Signature, as far as I have seen.

In some countries an invoice must be digitally signed so that the
receiver can pre-getback the tax (dont know the right term in English /
Vorabsteuer beziehen in German).

So for the dsig part:

a) it must simply get cheaper that SME's (including one man companies)
can afford a certificate signed by one of the authorities (one that is
OK for the countries tax agencies). Maybe 10$ a year but not more.

b) a javascript that before it sends the UBL invoice opens a dialog to
load the private key to sign the UBL invoice and then sends the UBL
invoice or

c) have a browser plugin to do the signing. A plugin may have more
rights to access the computers harddisk to retrieve the private key so
the user must not manually select the certificate

c) the tool (javascript/plugin) should be Open Source so it is possible
to make sure the script does not maliciously send the private key
somewhere. 

Regards

Sacha

Am Freitag, den 10.11.2006, 11:50 -0700 schrieb David RR Webber (XML): 
> Fulton, 
>   
> Actually I'm deep into AJAX right now.  Oracle have an excellent open
> source toolset available. 
>   
> However - for me the power of the RIA approach is  
> 1) Layering the solution (which was the whole permiss to XML) so
> rendering, rules, form, xml all separate. 
> 2) Being able to make things agile and dynamically context aware (XML
> scripted) 
> 3) The DOM inside the browser client is way more powerful than anything
> we had before. 
>   
> So - unlike your model - I'm seeing - yes - we do those realtime RIA
> requests and updates - but what is happening is you are building up the
> information you need in the DOM at the client interactively.  Once its
> all complete - then you hit "Send" - and the RIA then packages the UBL
> transaction and dispatches it to the server for delivery.  That
> delivery could involve traditional B2B style reliable exchanges.  What
> you've saved is having to package / validate the XML on the server. 
>   
> Here's a recap' of how this works (layers details exposed): 
>   
> 1) RIA works with user and database to collect valid content to client 
> 2) DOM in client is updated with labelled data fields ( notice those
> labels match the UBL names....) 
> 3) Javascript invoked by "Send" button - it opens up a XML template of
> the UBL (hint: CAM templates work great!) 
>     and simply does substitutions matching data labels to structure
> placeholders.  This is "code free" + re-usable - 
>     if you change the template - add more fields - then the "Send"
> requires zero changes. 
> 4) UBL XML transmitted to server via browser XML send command. 
> 5) Server places XML in outbound queue for sending via secure B2B
> system. 
>   
> What is way crazy about all this is that Duane and I built a prototype
> for this back in 1999 for a example selling products - simple catalogue
> in XML, pick, buy.  Javascript + DOM + XML = very slick! 
>   
> DW
>  
> 
> 
>  -------- Original Message --------
> Subject: [ubl-dev] UBL payload and client-server integration tools
> From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
> Date: Thu, November 09, 2006 6:58 pm
> To: 'Stephen Green' <stephen_green@bristol-city.gov.uk>,
> ebxml-dev@lists.ebxml.org, ubl-dev@lists.oasis-open.org
> 
> Stephan et al:
> 
> I am leveraging your note regarding UBL payload, but in a somewhat
> different
> context - hence the different subject line. The parallel with your note
> is
> that there are various ways to leverage the payload IP of UBL, even
> though
> the middleware and transport would be something different. 
> 
> As is widely known, there are various tools and techniques used to
> recreate
> client-server selective updates, under the rubric "rich internet
> applications" (RIA). For example Adobe's Flash brings back 1990's style
> field-at-a time-update/validation with "Flash Remoting." Flash is
> certainly
> not the only RIA option, but it holds some high ground because of the
> ubiquity of Flash agents.
> 
> For reference, see http://www.amfphp.org, which is the home page of an
> open
> source Flash Remoting gateway. As it happens, the example shown on that
> page
> is a configuration-style order transaction for pizza. Presumably, as the
> user adds or deletes ingredients, the client-side software updates the
> price
> and perhaps validates the feasibility of the pizza, via calls to the
> server.
> Given that client-server responses need to flow consistently with the
> user's
> thought processes and rate of data input, RIA proponents are concerned
> about
> performance and therefore prefer binary data transfer rather than text
> and
> cannot afford a lot of XML overheads.
> 
> As RIA tools become more commonplace and accepted, thousands of
> programmers
> will use RIA calls to create or to consume what are or should be UBL
> transactions. Unfortunately, designers in the RIA world tend to be
> unaware
> of any of the relevant payload standards or are dismissive of those
> standards because they do not see a way to achieve high performance with
> text. There is also the issue that for RIA there may be a marked
> preference
> for dealing with a UBL transaction in pieces rather than as an entire
> document - e.g., call for the deliver-to address first to see if the
> vendor
> even wants to consider this order.
> 
> What are the implications of fairing UBL into RIA architectures?
> 
> One proposition would be to repackage UBL for RIA client-server use.
> Doing
> so is particularly helpful in avoiding a downstream need to translate
> some
> ideosynchratic ad hoc transaction design into something useful to the
> other
> party to the transaction. 
> 
> 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.
> 
> It is still early days for RIA, but perhaps not too early to consider
> the
> implications for UBL and other Oasis standards.
> 
> 
>                                       Fulton Wilcox
>                                       Colts Neck Solutions lLC
> 
> 
> 
>  
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
> Sent: Thursday, November 09, 2006 3:51 AM
> To: Stephen Green; ebxml-dev@lists.ebxml.org;
> ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] A UBL Customisation (beta) for general use
> 
> Offlist I was reminded that assimilation of the payload
> is the key consideration here so I guess we're talking
> fast infoset for the binary so as to allow the payload
> to be treated similarly to XML for those used to XML
> but for those receiving messages who already have
> telecoms technology then other binary formats may
> be appropriate.
> 
> Stephen Green 
> 
> >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 08/11/06 16:23:14
> >>>
> Hi David,
> 
> Is this confusing ASN.1 and AS2?
> 
> I think the use of ASN.1 would be non-XML payloads using one of 
> several binary formats which rely on a schema written not in XSD
> but in ASN.1 notation (though mappable to XSD). It gives the 
> advantage of preformance and/or small size and allows greater
> compression than with .zip or .gz, I believe. I think it predates
> XML in its use in the telecoms industries but nicely complements
> XML now that the latter is at the fore. So we are here talking
> payload, but with some bearing on other layers perhaps. And
> I guess what I'm after is any info on whether/how ebXML layers 
> might need adapting to cater for it (e.g. I guess the list of schema
> formats in the ebBP references to schema type won't include 'asn.1'
> so implementers might have to use 'other') - plus any general
> stories about successful use or otherwise of the ASN.1 provisions
> in UBL - either with ebXML or otherwise. Would, in fact, it be
> prudent/advantageous to use ASN.1 with ebXML? Or - a key
> question - is there already a preferred framework used with such
> binary payloads? I haven't come across any previous questions
> about this on these lists so maybe this is still virgin ground. It
> could be important for large files though.
> 
> All the best
> 
> Stephen Green
> 
> 
> >>> "David RR Webber (XML)" <david@drrw.info> 08/11/06 15:32:29 >>>
> Stephen, 
> 
> I just noticed this post.  This week on the Hermes 2 dev list - some
> people are looking to use Hermes 2 as
> a bridging server.
> 
> Basically Hermes 2 is pluggable - and supports both ebMS and AS2 - so it
> can talk on either channel.
> 
> You'd have to have something in between to extract payload and then
> repackage it - but I suspect all the parts are there to make it so.
> 
> Cheers, DW
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [ubl-dev] A UBL Customisation (beta) for general use
> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
> Date: Thu, November 02, 2006 11:44 am
> To: <ebxml-dev@lists.ebxml.org>, <ubl-dev@lists.oasis-open.org>,
> <stephen.green@systml.co.uk>
> 
> By the way, folk might note, following on from UBL's packages,
> we included a set of ASN.1 schemas for our subsets.
> 
> Has anyone actually managed to implement UBL with ASN.1
> and are they able to comment on their experience of this?
> I'd be especially interested to know what might be involved
> using ASN.1 with ebXML, such as ebMS. Is it feasible? I
> suppose it would mean transforming the binary into MIME.
> What would be the preferred binary format and how would
> MIME handle it? What values would be in the ebXML artefacts?
> Are there any products doing this?
> 
> All help appreciated.
> 
> All the best
> 
> Stephen Green
> 
> 
> 
> 
> >>> <stephen.green@systml.co.uk> 01/11/06 15:07:10 >>>
> I'm happy to say, on behalf of SystML, we have finished a beta
> customisation of UBL versions 1.0 and 2.0 which is freely available
> at
> 
> www.systml.co.uk/xml/ 
> 
> for use at your own risk. We hope you will provide feedback which
> could go to us at
> 
> info@systml.co.uk 
> 
> It was produced by SystML and by HavanaWave AG
> (Sacha.Schlegel@HavanaWave.com).
> 
> Obviously, it being at the beta stage, it is subject to possible
> change (though we'd bear in mind that we should consider possible
> users when contemplating any change) and how you use it is up to
> you provided you do so at your own risk. Maybe if this is all
> sufficiently satisfactory we will find the means to preserve it,
> long term, as it is (perhaps just changing the status to 'complete').
> Zip packages are provided for those who prefer the possible extra
> security of storing it locally (much as you would with the source
> code of opensource, say).
> 
> I'm very grateful to all who've helped us with this project to get
> it to this stage - to God and to colleagues : Thanks.  :-)
> 
> All the best
> 
> Stephen Green
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> ---------------------------------------------------------------------
> 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
>