[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [ebxml-dev] RE: [ubl-dev] UBL payload and client-serverintegration tools]
Dear ubl-dev Group Unfortunately I used a different email address and my response to David's comment did not make it to the ubl-dev team. Here is email. Sacha
--- Begin Message ---
- From: Sacha Schlegel <sacha@schlegel.li>
- To: "David RR Webber (XML)" <david@drrw.info>
- Date: Tue, 14 Nov 2006 09:57:17 +0100
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 >--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]