RE: [ebxml-dev] Best practise for entering multiple uri's inanebXMLdocument?

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

Dale

I notice the 'type' attribute in your example (with type="schema"):

<BusinessDocument nameID="IDO1000" name="UBL Order 1.0">
        <Specification nameID="UBLPurchaseOrder" name="UBLPurchaseOrder"
            location="http://www.acme.com/UBL-Order-1.0.xsd";
type="schema"/>
 </BusinessDocument>

Could this have a value to specify what UBL would describe as
a 'subset' or subset definition/declaration? Perhaps the value
"subset" as in:


<BusinessDocument nameID="IDO1000" name="UBL Order 1.0">
        <Specification nameID="UBLPurchaseOrder" name="UBLPurchaseOrder"
            location="http://www.acme.com/UBL-Order-1.0.xsd";
type="schema"/>
        <Specification nameID="UBLPurchaseOrderSBS" name="UBLPurchaseOrderSBS"
            location="http://www.acme.com/UBL-Order-1.0-SBS-1.0.xml";
type="subset"/>
 </BusinessDocument>

Is there a codelist for values for 'type' or is there likely to be one?

Thanks again

Steve


>>> "Dale Moberg" <dmoberg@cyclonecommerce.com> 04/05/05 19:25:26 >>>


-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Wednesday, May 04, 2005 10:19 AM
To: ebxml-dev@lists.ebxml.org 
Cc: ubl-dev@lists.oasis-open.org 
Subject: Re: [ebxml-dev] Best practise for entering multiple uri's inan
ebXMLdocument?

Folks,


Stephen Green writes
To clarify my previous posting, this is how my example looks at present
(based on ebBPSS1.04.xsd):


<BusinessDocument name="UBL SBS Invoice"
nameID="UBL-1.0-SBS-1.0-Invoice"
specificationID="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.
0 urn:oasis:names:tc:ubl:xpath:Invoice-1.0:sbs-1.0"
specificationLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/mai 
ndoc/UBL-Invoice-1.0.xsd [...]/xpaths/xml/XPath/Invoice-XPath.xml"> 

<Documentation> The documents are an XSD file and a subset definition
that specify the rules for creating the XML document for the business
action of invoicing the buyer. </Documentation> 

</BusinessDocument> 

Is this a misuse of ebBPSS?

DaleMoberg> 

The lack of a way to enumerate multiple specifications pertaining to a
BusinessDocument was a specific issue lodged against 1.x versions of
BPSS. It is resolved in 2.0 by shifting from an attribute to an
(unbounded) sequence of Specification elements looking like:

<BusinessDocument nameID="IDO1000" name="UBL Order 1.0">
        <Specification nameID="UBLPurchaseOrder" name="UBLPurchaseOrder"
            location="http://www.acme.com/UBL-Order-1.0.xsd";
type="schema"/>
 </BusinessDocument>


So for your example,several Specification elements would be used instead
of trying to create a space separated list in the attribute.


Can it be done a better way (e.g. in BPSS 2.0)?

Dale> See above. The TC has approved 2.0 several weeks ago.

Can the same be done with ebCPPA and ebMS?

ebCPPA 2.0 (and the working drafts on 2.1) all allow multiple Namespace
declarations as needed to identify those used in an XML document. For
ebCPPA, it would be used to express an agreement to support document
exchanges where the data is drawn from those Namespaces.

I think ebMS would not need to use the Namespace information for its
protocol. However, Namespace information can be part of the information
about the arrival of a BusinessDocument that an ebMS might publish as an
Event to be consumed by a subscribed a BPSS monitoring software
component. This is because the BusinessDocumentEnvelope language used in
described BPSS transitions needs to be "operationalized" so that
arriving messages can be recognized as events of the right kinds.