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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl-sbsc] UBP 2.0 definitions needing CPA templates


Many thanks Monica, this is very helpful, (hence my including it in
mail to ubl list
and not just sbsc - hope that's OK)

There are three use case of which I am mindful at present, all real:

1. The invoice or other document is incomplete in itself as the document
started life as a paper document but was then scanned into some (pdf?)
electronic form with just some of the resulting data captured using optical
character recognition (as with well known danish government use case).
So here the binary file contains the great part of the document, while the
XML part is that which a system needs for storage and updates to the finance
system. What then if there is a need to transact with the combined data
using ebXML?

2. There is then the case where the main document is almost self-contained
as some XML format but there is additional data in the form of, say, a pdf file
which has, by law, to accompany the XML document. This could be an order
in UBL which has associated specifications in pdf format. Without the pdf
files it might be illegal to complete the order creation process.

3. The other use case in my mind is where there is an accounting XML general
ledger file (say XBRL-GL) which has to be transferred between a department of
a complex organisation and its centralized accounting department, perhaps
in another country, or even another organisation responsible for the accounting,
such as one from which its work has been outsourced or offshored. The general
ledger file (as with XBRL-GL) has associated with it, perhaps as 'attachments'
a set of business documents such as XML orders and invoices (say, UBL) to which
the ledger entries relate. The ledger entries refer to such documents,
perhaps with
xlink or XPath (or maybe even mime). One way is to actually embed the documents
inside the ledger document but then there would be the need for escaping and
complex handling for validation (NVDL tools not having become
commonplace yet :-)
There could be a mixture of some XML orders and invoices (some UBL, others
something else) and some binary, say pdf files, perhaps some files in EDI too.
There might or might not be business rules that require that there be conditions
related to not just the 'parent' file (Note in some cases, to
complicate things,
the parent file might be the invoice with the ledger as 'attached'
even) but also
things about the attached files' contents or presence. These conditions might be
requirements for business success/failure (a file attachment might be required
or might be required to be valid or in a particular namespace or
mime-type, etc, etc).

Can all the above use ebBP and other parts of the ebXML framework
'out-of-the-box'
as it were? maybe there is the need in some of these cases for two or more
transactions, one perhaps using the UBL AttachedDocument (which, I
gather, says in
effect 'these documents sent in separate messages or transactions go together
as if they were attached to oneanother'). I envisioned the
AttachedDocument process
(the actual transaction which has that document as its business document) as a
Notification pattern which can be combined with other transactions (in
UBP's case
either separate transactions/collaborations or separate transactions
correographed
into a combined collaboration).

Sorry to be so detailed.

All the best

Steve


On 08/03/06, Monica J Martin <Monica.Martin@sun.com> wrote:
> See inline.
>
> >green: Regarding attachment, I'm a little put off by the definition of
> >attachment in ebXML which says it is binary and without semantic meaning. I think most
> >attachments to SBSC-scope business documents would fall out of that category (the main ones are
> >pdf's carrying extra semantic information not found in the essential business
> >document XML part, such as the Danish government folk use, I believe, or there
> >are XML attachments which are excluded from the ebXML definition of attachment
> >in this context too).
> >
> mm1: It says that an attachment may be "any other structure, or
> completely unstructured (e.g. related to images, EDI, binary data)". You
> have to look to the meaning behind this. There is to be one LOGICAL and
> PRIMARY business document (substantive) that is part of the
> DocumentEnvelope that may also contain 0..n "unstructured" attachments.
> They are not interrogated within the Document Envelope, i.e. condition
> expressions and variables aren't used on them. Quality of service,
> specification and documentation although apply to the unstructured (as
> well as the structured information) in the DocumentEnvelope.
>
> There can be more than one specification for a logical business document
> (i.e. Uses different namespaces, each of which has a schema, any or all
> may be specified using a sequence of Specification elements). At first
> glance this may apply to the Danish government usage.
>
> If there is a need to be able to separately interrogate attachments
> (such as in addition to that for the logical business document of which
> may have many specifications to compose and for example in the context
> of the use of variables and condition expressions), this should come
> with a use case and requirements or questions. There was much discussion
> about attachments in the evolution of ebBP v2.0, as there was Asia
> specific input on attachment changes.
>
> >
> >Incidentally, I'm inclined to separate the UBP 1.0 out of the UBL 1.0
> >SBS package
> >into its own candidate committee specification, if the rules allow it.
> >This would allow
> >the SBS to proceed but the UBP to wait for further progressing of the
> >ebBP toward
> >full standardisation in case the UBP otherwise falls foul of necessary
> >changes to
> >the ebBP. It would be ideal to progress both package as soon as possible but I'd
> >not like to see users of the UBP having problems, say, with Includes
> >if they are using
> >the Standard schema for their derivatives but have to use an earlier
> >schema for the
> >included, inherited process definition. Is there any rsik of the ebBP schemata's
> >namespaces having to change (e.g. to '...ebxml-bp...' from
> >'...ebxmlbp...'?
> >
> mm1: We will have to negotiate this with OASIS. The schema are currently
> 'ebbp' and I'd prefer to keep it that way.
>
> > If not it
> >won't hurt to have the two packages separate as for UBL 2 anyway and
> >they can both
> >progress at the same time. I'm inclined to see the UBP as distinct
> >anyway. If there
> >is a problem with the UBP 1.0 getting from where it is as part of the
> >SBS package
> >to committee spec without having had all the review it needs (it
> >missed the first, 50 day
> >SBS public review and just had a 15 day review, I think), my own idea
> >for a contigency
> >plan is to combine the UBP for 1.0 with that for 2.0 and submit them
> >all for the 50 day review together if SBSC and the TC agree.
> >
> mm1: Well to have a contingency plan because I am uncertain you can
> change the path midstream.
>
> >
> >Either way, I feel safer changing the UBP 1.0 package yet again to refer not to
> >ebxmlbp-2.0.2 (or -2.0.3) but ebxmlbp-2.0, or whatever the stable name will be.
> >Hence, if it needs to be changed again before it gets through the process it can
> >be given a new release id without affecting the SBS.
> >
> >Any thoughts?
> >
> mm1: See previous comment.
>
> >>schlegel: ...2) Still generate the sample CPA's but set the CPA status value to
> >>'proposed'. How to recognize a generic UBP? ProcessSpecification nameId
> >>attribute starts with "Generic" or uuid attribute includes generic in
> >>its seventh component (separated by colon :)?
> >>
> >>
>
>
>


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