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

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

Thanks Sacha for this suggestion. I'm happy to go with your judgement for
option 2. Any others having opinions on this?
I'd be wary at this stage of separating the generic definitions
(proto-definitions?)
into a separate directory to help handling as this would force a separate url in
the package so the algorithms you use look OK and 'generic' is
unlikely to appear
in a UBL document type name to cause an error if that is the criterion.

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).

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...'? 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.

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?

All the best

Steve




On 08/03/06, Sacha Schlegel <sschlegel@cyclonecommerce.com> wrote:
> Hi Steve
>
> Good thing you raise the question. I admit I did not think when you
> added "generic" ebBP's but simply run them as all the others.
>
> I agree that a "in production" CPA's (probably with 'agreed' status
> value) should only include real business documents and not a
> placeholder. At the same time a "in preparation" CPA (probably with
> 'proposed' status value) can include anything and it is then up to the
> parties to finalize it (eg replace all placeholders with actual values).
>
> So I think what we should do is the following:
>
> 1) Either exclude the CPA generation for the generic ebBP's; only
> produce the ebCPPA building blocks.
> 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 :)?
>
> I am open to any of the above. I suggest choice 2.
>
> Concerning CPP's, actually that would be nice to demonstrate. What we
> (as ebXML messaging with ebXML CPPA software implementer) realize is
> that currently ebXML endusers omit CPP's but create directly the CPA's.
> Nevertheless it would be neat to have CPP's as well. That will trigger
> the question how to get from two CPP's to a CPA.
>
> BTW. Did you see Pim's ePV Feedback document? It demonstrates the use of
> Attachment in  DocumentEnvelope element.
>
> Regards
>
> Sacha Schlegel
>
> On Tue, 2006-03-07 at 11:48 +0000, Stephen Green wrote:
> > Sacha , cc SBSC and Monica due to discussion below
> >
> > Hi Sacha, This is where the time differences between UK and US come in handy:
> > I do apologise but I only just realised you were generating CPAs for the generic
> > definitions too so we'll need them for the attached too as well as the
> > one I sent earlier.
> > Sorry.
> >
> >
> > I wonder what the implications of having CPAs for the generic
> > definitions will be.
> > Is there a way to use the generic definition unchanged? Normally it would be
> > included into another to specialize it with attribute substitution
> > (I'd like to see
> > a demo of that as I'm not yet sure how it would work) for a particular schema
> > (typically other than UBL, though it could be another, say future,
> > version of UBL
> > or a customisation perhaps). What would happen if they were left as they are and
> > referenced in the CPAs as they are? On the other hand I appreciate the benefit
> > of illustrating a CPA referencing the generic definition as this may minimise
> > changes when the definition is specialized and needs to be referenced. But if
> > the CPA references the generic definition does that actually prove
> > useful in some
> > way? Can a CPA be that generic?
> >
> > Any comments welcome :-)
> >
> > All the best
> >
> > Steve
>
>