[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-dev] Best practise for entering multiple uri's inanebXMLdocument?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]