[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] RE: [ubl-dev] RE: [ebxml-dev] Best practise forentering multiple uri's inanebXMLdocument?
>Moberg: <xsd:simpleType name="DocumentSpecificationType">
> <xsd:annotation>
> <xsd:documentation>The simpleType related to the
>enumerated list of specification types
> for the Specification element. Note: This simpleType was
>added in v2.0.</xsd:documentation>
> </xsd:annotation>
> <xsd:restriction base="xsd:NMTOKEN">
> <xsd:enumeration value="schema"/>
> <xsd:enumeration value="dtd"/>
> <xsd:enumeration value="wsdl"/>
> <xsd:enumeration value="relaxng"/>
> <xsd:enumeration value="other"/>
> </xsd:restriction>
> </xsd:simpleType>
>
>
>"rddl" might be another value for this enumeration but there wasn't
>critical mass to add it yet. The enumeration is sort of like a code
>list, but we have not tried to make the enumeration simple type easily
>extensible at this point.
>
>So far, these values are mainly hints for software hoping to relate the
>more "logical/abstract" document envelope value (which references a
>BusinessDocument) to some more specialized realizations of the
>BusinessDocument. The values can also be propagated down to CPPs and CPA
>templates formed when given a BPSS instance (and the selected role to
>play in the process) as input.
>
>We have a few weeks window before we move ahead with BPSS 2.0 (probably
>in a BPSS 2.0.1 version). So I will forward this question to the TC to
>consider. If you have more information for us to consider, please post
>to the ebxml-bp-comments list (it would be a welcome break from the
>spam!)
>
>
mm1: We'd invite you to join the call Stephen. We meet each Tuesday at 9
a.m. PDT (866 882 3998, passcode 9081038#). The international number is
865 525 0769. You can review the technical specification (of four
packages) [see below]. The Committee Draft v2.0 was approved
unanimously 21 April 2005.
* core:
http://www.oasis-open.org/committees/document.php?document_id=12259&wg_abbrev=ebxml-bp
(Note that the example v2.0 instance uses UBL)
* signal:
http://www.oasis-open.org/committees/document.php?document_id=12260&wg_abbrev=ebxml-bp
* supplements:
http://www.oasis-open.org/committees/document.php?document_id=12262&wg_abbrev=ebxml-bp
* artifacts:
http://www.oasis-open.org/committees/document.php?document_id=12261&wg_abbrev=ebxml-bp
If you intend to attend, please let me know so I can assure this item is
on the agenda. Thanks for your feedback.
>-----Original Message-----
>From: Stephen Green [mailto:BRITSDG@bristol-city.gov.uk]
>Sent: Thursday, May 05, 2005 3:49 AM
>To: ebxml-dev@lists.ebxml.org
>Cc: ubl-dev@lists.oasis-open.org
>Subject: [ubl-dev] 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.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]