RE: [ubl-dev] Specifying use of a profile with CPP

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Dale

I very much appreciate your comprehensive and considered reply.


On the matter of the uuid in tp:ProcessSpecification, I'd prefer actually to use the BPSS document filename and a urn of the BPSS owner, something like:

<tp:ProcessSpecification tp:version="***" tp:name="bpss-doc-filename.xml" xlink:type="simple" xlink:href="****" tp:uuid="uri:com.companya:bpss-doc-filename.xml"/>

or a similar technique if not using BPSS. However, I'll consider this further in view of your comment about the Service in ebMS.


I guess I should ideally look forward to CPPA 2.1 but these comments and explanations are a great help in the meantime.

I will also look forward to UBL having a permanent Schema location, as seems to be all the more important in the light of these requirements.

The need for a fixed location for a UBL Lite specification is also highlighted.

Many thanks

Stephen Green



>>> "Dale Moberg" <dmoberg@cyclonecommerce.com> 09/09/04 17:03:46 >>>
Stephen Green asks some good questions and I have _some_ replies below :

Subject: [ubl-dev] Specifying use of a profile with CPP

Greetings

I've some questions about ebXML CPP in relation to UBL as an ebXML
payload.


1. For someone using UBL Lite as a profile, is it possible to specify
use of a profile in CPP? Using the CPP Schema, tp:NamespaceSupported
element I can specify:

<tp:NamespaceSupported tp:location="UBL-Order-1.0.xsd"
tp:version="ubl-lite-0.2">urn:oasis:names:specification:ubl:schema:xsd:O
rder-1.0</tp:NamespaceSupported>

but I imagine it might not be proper to use the tp:version attribute in
this way.

DaleMoberg> The CPPA TC is currently working on a maintenance version
2.1 whose main purpose is to add extensibility points. So I will also
copy this response to that TC list. What we have added to
NamespaceSupported is an anyattribute element to the schema to allow the
addition of other needed attributes. The version attribute is required
in version 2.1 CPPA as is
location.

Also, if you use BPSS in conjunction with a CPP, the BusinessDocument
element can there provide additional
information about what documents are exchanged in the
BusinessTransactionActivity. There is still some question about whether
mentioning syntactical details about a document in BPSS impedes
reusability by violating its abstraction level.
If so, probably CPP and CPA should have better provisions for
documenting (under SimplePackage or elsewhere) information needed in a
collaboration agreement. For example, information about context has been
suggested as something
we should make room for or, more grandly, a whole recipe for
constructing the document/businesspayload from bits and pieces of schema
or similar specification notations.


Also, in the above example it seems the emphasis is on the location of
the Schema rather than the namespace;

DaleMoberg>The element's content is anyURI which is the namespace
identifier. 
location is just an attribute, which was zeroOrOne in 2.0 but is now
required in 2.1. Without a location in the
agreement, it is a little less "nailed down" about what schema
definitions have actually been agreed upon in production. 

 the example CPP document given actually uses the Schema location in the
text of the element too. I took the liberty of using the namespace of
the UBL document in the element text content but is this correct? 

DaleMoberg> Exactly what was intended because NamespaceSupported has
type "anyURI". Maybe that wasn't made clear enough in the specification.
I will go back and check. Anyway you are doing it in what should be the
supported way.

UBL doesn't yet have a permanent  loaction so I'm perturbed at the
emphasis on location in what should be by definition a specification of
support of a namespace rather than a physical Schema file.

DaleMoberg> Hmmh. There may be a difference in that namespaces can be in
practice variously defined by different
schema files all claiming the same targetNamespace. So without location
it "seems" more ambiguous.  True, even with
location, I guess people could replace the actual file by some other
one, once the agreement is in place and so
alter the agreement. But we have not worried about that yet. [We do use
hashes from xmldsig to nail down other
referenced documents for the truly paranoid and/or lawyers :-)]

2. Does one have to wait for an official BPSS definition of UBL
processes to be defined in order to use UBL with CPP?

How can I get appropriate values for:

<tp:ProcessSpecification tp:version="**" tp:name="*******"
xlink:type="simple" xlink:href="*****" tp:uuid="******"/>

in order to specify use of UBL in my CPP document?

DaleMoberg> We so far only explain this for BPSS. If you use some other
process specification, you will need
to create conventions for its reference. [With interoperability waiting
until your conventions catch on...] Again, the extensibility options for
ProcessSpecification are being finished for 2.1 and so far we have not
had a lot of input on requirements in this area. 

3. Pushing this further, what would be required in order to specify use
of a defined subset/profile of UBL such as UBL Lite? I would imagine
something like <tp:ProcessSpecification tp:version="2.0"
tp:name="ubl-lite-0.2" xlink:type="simple"
xlink:href="http://lists.oasis-open.org/archives/ubl-dev/200409/msg00002 
.html" tp:uuid="*******"/> but this would be a desparate measure and it
still doesn't give me a tp:uuid. 

DaleMoberg> I agree that examples of extensibility in the
ProcessSpecification have not been published. Actually
maybe we could use your convention to illustrate how this can be done.
There is a lot of concern about the uuid
value which was arrived at as a way for BPSS users to "suggest" a value
to be used in ebMS "Service" That solution
looks like it won't work as we move to multiparty BPSS involving more
than one Service. This topic is still not resolved for the 2.1
maintenance version. So, what would you like to be able to do (in 2.1
anyway)? 

What I would do for "uuid" in a 2.0 context when not using BPSS is to
select a value that would be informative about what "Service" you would
like announced within ebMS. That is the main implication existing
software would propagate across the ebXML components.



4. ** Does this all mean we can't use CPP without there having been
substancial BPSS and registration work already done at a standards
level? **




I'd appreciate any help or comments

Stephen Green