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

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

Sacha

I've created a handedited UBP 1.0 separate package in which I've hand-edited
the filenames for the ebBP schemas to '...2.0'. It would be ideal if
you would be
able to create a set of files as close to this as possible such that
we could switch
the CPA files from the handedited ones to the completely generated ones. I also
'corrected' the relative path references for the ebBP definitions in
the CPA files
to the expected absolute ones (assuming cs - which might have to be changed
temporarily to prd if we have to have another review, but then we could think of
comibining UBP 1.0 with UBP 2.0 anyway, and save extra work). All the filepaths
which are absolute had to be changed for this extra-SBS version. There
are probably
three weeks left for this work before a vote is needed in which to
make any minor
edits and think about the route this takes.

The UBP 1.0 proposed draft cs package is at
http://www.oasis-open.org/committees/document.php?document_id=17039&wg_abbrev=ubl-sbsc

The UBL 1.0 SBS without the UBP is at
http://www.oasis-open.org/committees/document.php?document_id=17038&wg_abbrev=ubl-sbsc
(draft #3)

All the best

Steve

On 08/03/06, Stephen Green <stephengreenubl@gmail.com> wrote:
> 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
> >
> >
>