[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Treasury Tag Pattern: to 'glue' two instances havingdifferent schemas
Stephen: Have you considered using xs:import? This is exactly what the W3C developed it for. <?xml version="1.0" encoding="UTF-8"?> ... <xs:import namespace="urn:publicid:IDN+cde.foobar.edu:schemas:something:us" schemaLocation="http://www.foo.com/someChunkOfUBL.xsd"/> <xs:import namespace="http://www.w3.org/1999/xhtml" schemaLocation="http://www.bar.com/anotherChunkOfUBL.xsd"/> ... It would be better to stick with industry supported standards for this since this is widely supported in most parsers like Xerces. Duane Stephen Green wrote: >I note an errata below: > >The ATG2 SBDH package has a pattern >suggesting that the top element (the tag >name of the 'Treasury Tag') is called >StandardBusinessDocument > >An example of how part of such a document >might look: > > ><?xml version="1.0" encoding="UTF-8"?> ><StandardBusinessDocument >xmlns="StandardBusinessDocument" >xmlns:xbrli="http://www.xbrl.org/2001/instance" ... >xmlns:gl-cor="http://www.xbrl.org/taxonomy/int/gl/cor/2003-08-29/" >... >xmlns:po="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0" >... >xsi:schemaLocation="StandardBusinessDocument > StandardBusinessDocument.xsd"> ><!-- not all the various namespaces needed to have been declared here --> ><xbrli:group >xmlns:xbrli="http://www.xbrl.org/2001/instance" ... >xmlns:gl-cor="http://www.xbrl.org/taxonomy/int/gl/cor/2003-08-29/" >... > > ><gl-cor:accountingEntries> >... rest of XBRL-GL ledger document ... ></xbrli:group> ><po:Order >xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0" >... >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0 >http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/maindoc/UBL-Order-1.0.xsd"> ><po:SellersID>CON0095678</po:SellersID> >... rest of UBL Order document ... ></po:Order> ></StandardBusinessDocument> > > >The schema for this StandardBusinessDocument >would have the document schemas imported >and just the single element and complex type: > ><xsd:element name="StandardBusinessDocument" > type="StandardBusinessDocumentType"/> ><xsd:complexType name="StandardBusinessDocumentType"> > <xsd:sequence> > <xsd:element ref="po:Order"/> > <xsd:element ref="xbrli:group"/> > </xsd:sequence> ></xsd:complexType> > > >I'd suggest that there are the following reasons >for the Treasury Tag / StandardBusinessDocument >pattern above: > >1. specifies interface between, say, finance systems >2. facilitates storage >3. facilitates processing such as to flat file for legacy systems >4. facilitates simplicity of specification for interoperability > such as "must use XBRL-GL + UBL + ..." > > >All the best > >Stephen Green > > > >----- Original Message ----- >From: "Stephen Green" <stephen_green@seventhproject.co.uk> >To: <ubl@lists.oasis-open.org>; <ubl-dev@lists.oasis-open.org> >Sent: Monday, July 11, 2005 8:49 AM >Subject: [ubl-dev] Treasury Tag Pattern: to 'glue' two instances having >different schemas > > > > >>Regarding the issue of how to bring together a document and data from >>another schema (thanks to Duane for the suggestion along the lines below): >> >>I guess what we need is the XML equivalent of a 'treasury tag'. >>This treasury tag is then a 'pattern' (in the software design sense) >>rather than a specific schema. >> >>It goes something like this: >> >>Treasury Tag Pattern >>------------------------ >> >>Requirement: a way to clip together two or more XML documents >>so that these can be treated as a single file. >> >>Structure: >>A schema is created with a document top level element. The top level >>element can have any name but a suggestion is 'StandardDocument'. >>This acts as a container element to one or more elements which >>are the document top level elements of the XML files to be contained. >>The schema imports the schemas of the contained XML files. >> >>Consequences: >>There is no need to use xsd:any and all data may be associated >>with namespaces >>This has the following benefits and liabilities - >>benefits - data is more easily recognised as being appropriate >>liabilities - a schema has to be created for each set of documents >>There is also the benefit that the set of documents may be validated >>as one. >>For storage it may be preferable to remove the containing element >>so that each document is stored separately with its own namespace >>and types. >> >> >>All the best >> >>Stephen Green >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >> >> >> > > >--------------------------------------------------------------------- >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]