[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]