[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Specifying use of a profile with CPP
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]