OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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 having different schemas


Duane

Hi. Yes, I'd see the import as important,
please forgive the pun :-) , but I'd also
see having a separate top, document
element as necessary to create the valid
instance without there being an xsd:any
in either of the two or more imported
schemas. The only 'standard' name we
seem to have for this element is
'StandardBusinessDocument' being
standardised by CEFACT/ATG2.

Since we are avoiding use of xsd:any
and since we have any number of different
schemas which might be imported, we
cannot have (can we?) any one single
schema defined but have to create one
for each combination of imported
schemas. This is obviously a weakness
since it gives the reciever of a message
little control (apart from trading agreements)
over the top part of the combined instance.

I'd prefer that we had a schema with
a multi-occurance xsd:any element/type but
in its absence I'd settle for a pattern as
above and hope that it provides at least
some interoperability - essentially it means,
I think, the establishing of a convention.

On the whole I'm trying to promote the
due consideration of whether it is better
to have a convention without a
standardised schema or whether we can
have a schema that involves use of
xsd:any.

In the meantime we might at least settle for
the convention.

All the best

Steve



----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
To: "Stephen Green" <stephen_green@seventhproject.co.uk>
Cc: <ubl@lists.oasis-open.org>; <ubl-dev@lists.oasis-open.org>
Sent: Tuesday, July 12, 2005 3:19 PM
Subject: Re: [ubl-dev] Treasury Tag Pattern: to 'glue' two instances having
different 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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]