OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]