[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [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]