[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Processes
Greetings Jan I was sent some details about the CEFACT SBDH "Until the unece.org link is restored, here are direct links to the specification: http://www.uncefactforum.org/ATG/Documents/ATG/Downloads/CEFACT_SBDH_TS_version1.3-03.zip and the schemas: http://www.uncefactforum.org/ATG/Documents/ATG/Downloads/SBDH20040506-02.zip " (Thanks Dale) I generated a sample of what a minimal UBL Order with an SBDH might look like, below. The SBDH looks large in proportion to the Order but that is because the Order is very much abbreviated and my SBDH sample has two of every multi-occurrence element. All this is really to point out that the SBDH has a Sender//EmailAddress, etc. <?xml version="1.0" encoding="UTF-8"?> <StandardBusinessDocument xsi:schemaLocation="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader StandardBusinessDocumentHeader.xsd" xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:n2="http://www.altova.com/samplexml/other-namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <StandardBusinessDocumentHeader> <HeaderVersion>String</HeaderVersion> <Sender> <Identifier>String</Identifier> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> </Sender> <Sender> <Identifier>String</Identifier> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> </Sender> <Receiver> <Identifier>String</Identifier> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> </Receiver> <Receiver> <Identifier>String</Identifier> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> <ContactInformation> <Contact>String</Contact> <EmailAddress>String</EmailAddress> <FaxNumber>String</FaxNumber> <TelephoneNumber>String</TelephoneNumber> <ContactTypeIdentifier>String</ContactTypeIdentifier> </ContactInformation> </Receiver> <DocumentIdentification> <Standard>String</Standard> <TypeVersion>String</TypeVersion> <InstanceIdentifier>String</InstanceIdentifier> <Type>String</Type> <MultipleType>true</MultipleType> <CreationDateAndTime>2001-12-17T09:30:47.0Z</CreationDateAndTime> </DocumentIdentification> <Manifest> <NumberOfItems>0</NumberOfItems> <ManifestItem> <MimeTypeQualifierCode>String</MimeTypeQualifierCode> <UniformResourceIdentifier>http://www.altova.com</UniformResourceIdentifier> <Description>String</Description> <LanguageCode>String</LanguageCode> </ManifestItem> <ManifestItem> <MimeTypeQualifierCode>String</MimeTypeQualifierCode> <UniformResourceIdentifier>http://www.altova.com</UniformResourceIdentifier> <Description>String</Description> <LanguageCode>String</LanguageCode> </ManifestItem> </Manifest> <BusinessScope> <Scope> <Type>String</Type> <InstanceIdentifier>String</InstanceIdentifier> <Identifier>String</Identifier> <BusinessService> <BusinessServiceName>String</BusinessServiceName> <ServiceTransaction/> </BusinessService> <BusinessService> <BusinessServiceName>String</BusinessServiceName> <ServiceTransaction/> </BusinessService> </Scope> <Scope> <Type>String</Type> <InstanceIdentifier>String</InstanceIdentifier> <Identifier>String</Identifier> <BusinessService> <BusinessServiceName>String</BusinessServiceName> <ServiceTransaction/> </BusinessService> <BusinessService> <BusinessServiceName>String</BusinessServiceName> <ServiceTransaction/> </BusinessService> </Scope> </BusinessScope> </StandardBusinessDocumentHeader> <Order xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Order-2 http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/maindoc/UBL-Order-2.0.xsd" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"> <cbc:ID>normalizedString</cbc:ID> <cbc:IssueDate>1967-08-13</cbc:IssueDate> <cac:BuyerCustomerParty/> <cac:SellerSupplierParty/> <cac:OrderLine> <cac:LineItem> <cbc:ID>normalizedString</cbc:ID> <cac:Item/> </cac:LineItem> </cac:OrderLine> <cac:OrderLine> <cac:LineItem> <cbc:ID>normalizedString</cbc:ID> <cac:Item/> </cac:LineItem> </cac:OrderLine> </Order> </StandardBusinessDocument> On 19/02/2008, Stephen Green <stephengreenubl@gmail.com> wrote: > Jan, > > Yes, this is how UBL was designed. Wherever appropriate these > application layer and message transport details were deferred to those > layers to avoid duplication and redundancy. Both ebXML-MS and WS-* > were in mind and anything else that might come along. There was some > work done outside UBL to standardise a 'standard business document > header' (CEFACT's SBDH) but I couldn't find a reference to it using > a Web search - it might have what you need. Can you not use the ebMS > header? If all else fails maybe you should resort to the Extension point > in UBL documents but that seems a little awkward since the document > itself is ideally packaged inside or attached to the messaging layer and > not the other way round. If it was me I'd start by trying to use the ebMS > header (3.0) to wrap the document. Failing that I'd send both document > and ebMS header as separate instances (if the transport supports two > instances that is - I don't know much about Atom). All very interesting. > Maybe some of the rest of the ebXML stack might be useful for this too. > > Best regards > > > > In UBL, are there elements that provide the information to a document > > receiver > > where to send the next message in the overall process to? I suppose > > this is > > subject to the actual cordination framework in use and deliberately > > out of scope > > for UBL itself, yes? > > > > IOW, if I received an UBL Order via email the sender's email address > > would be > > the target for my Order Reply. There is nothing in the UBL Order > > itself that I > > should (or: am allowed to) look at to find the target to reply to. Yes? > > > > Thanks - all this is helping a lot. > > > > Jan > > > > > > -- > Stephen D. Green > > Partner > SystML, http://www.systml.co.uk > Tel: +44 (0) 117 9541606 > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]