Re: [ubl-psc] New issues from Northern European Subset group

["Stephen Green" <stephengreenubl@gmail.com>]

Hi Martin

Mmm, but is the UN/CEFACT way for this a design-in-progress or is it
actually a standard way of doing things? Industry standards use message
headers, there's no doubt about that, when handling XML. How the
downstream process caters for that depends on the implementation
software but the message header is usually passed around the system in
some way, I think, not necessarily intact but rather as metadata passed
on from header to header or via XML routers with pre-configured
'knowledge' of what to do dependant on some metadata which needn't be
in the document itself but can be associated with the document in some way.
What might be needed is the same sort of thing as a content management
system uses - there the metadata doesn't mix with the content, ideally (MVC).

I'm still unconvinced but we do need to look at the detail. Is this just about
designing the document to match a particular product, for example? The
application of MVC principles and patterns and better still of the managed
public processes application pattern (as used with PIPs, etc) seem better
than to try to accommodate individual proprietary products and less optimal
patterns. I'd rather UBL were designed to the best patterns than designed
to products. That's if there is time and resources to do so of course.

All the best

Steve


On 14/03/06, Martin Forsberg <martin.forsberg@amnis.se> wrote:
>
> Stephen,
>
> The problem with envelopes like ebms´ is that it stays in the MSH, the
> internal systems works with only the payload. The payload must contain
> information about it's context. A standard business header is a better
> solution, but I have not seen any recommendation from UBL to adopt this.
> Correct me if I'm wrong, but I think that the idea of keeping the namespace
> intact after restrictions and contextualization is not really the un/cefact
> way of doing this. I think you will have to change your namespace if you
> restrict the cc and that is not helping interoperability. But if the
> namespace is the same over different contexts, some other solution is
> needed.
>
> Of course we will recommend to use trading agreements, but when working with
> 100 000+ e-business parties, it is hard to mandate transportation methods
> like ebms (though ebms is the recommended method of transporation i Sweden).
> The banks use their secure networks with other protocols.
>
> Regards,
> Martin
>
> ________________________________
> Från: Stephen Green [mailto:stephengreenubl@gmail.com]
> Skickat: ti 2006-03-14 11:34
> Till: ubl-psc@lists.oasis-open.org
> Ämne: Re: [ubl-psc] New issues from Northern European Subset group
>
>
>
>
> Martin
>
>
> > Further more, the first invoice might apply schematron rules not required
> for the second invoice. If the contexts are very
> > different, there even might be need for two differently restricted
> schemas.
>
> As with our codelist methodology the file we call an association file,
> which allows
> schematron validation, is not sent with the document and certainly not
> included in
> the document; it is a once-only setup file which is agreed between
> parties at the
> time they enter a trading agreement. I sympathise with a little metadata in
> a
> document but the use case you mention seems to be better solved with the use
> of a trading partner agreement.
>
> >
> > It is also possible that a supplier sends invoices based on the two
> contexts, depending on the products or services, to one buyer.
> > The invoices are transported via ftp/smtp/http to the same end-point. The
> buyer
> must be able to seperate the documents for internal
> > transportation to the correct system.
> >
>
> The contexts need to be identified and preconfigured in the systems at each
> end
> of the trading collaboration before any transactions are made, don't they?
> The
> standard way seems to be always to include a message header which contains
> pre-agreed id's and a look-up derives the context information already
> registered,
> etc for these id's (e.g. in a UDDI and/or RegRep registry or from some
> application
> or database). The least standard way but in line with the above seems to be
> to
> use something like the sender address of an email, looking it up
> locally and from it
> determining how to process the message, apply schematron for contexts,
> subsets
> and codelists, and maybe for transformations (though we haven't quite
> got that far),
> etc.
>
> In all the industry standard cases it seems that header or envelope
> information is
> used. Surely we need to keep to this. Duplicating header information in the
> body
> of the attached or embedded document may help if the message headers are
> under-standardized or unreliable but that is probably not the best
> thing to do. Better
> to standardise headers as in ebMS or create something equivalent for systems
> in which ebMS cannot be used. The standard may be SOAP (or REST) as the
> basis
> for such headers, rather than adding something new to the payload. If there
> are
> multiple payloads there would then be just the one place to find a manifest
> or
> equivalent.
>
> How about standardising the urls of the endpoints in the Internet
> system if that is
> what you are developing.
>
> Or how about we just nail it down as to where and why ebMS headers
> aren't applicable
> and seek to fill that gap or speed on the work of others already
> filling it in a standard
> way.
>
> I accept that the above may take longer but a quick fix might be more
> regrettable later
> and perhaps just adding the metadata to a document is a quick fix and
> duplicates
> the above as well.
>
> All the best
>
> Steve
>