Re: [ubl-dev] Treasury Tag Pattern: to 'glue' two instances having different schemas

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Folks

Looking closer at the SBDH 1.3, it doesn't allow more than
one document inclusion within the StandardBusinessDocument
tag so it is rather academic whether the SBDH itself should be
used for adding further data to documents.

<xs:complexType name="StandardBusinessDocument">
<xs:sequence>
<xs:element ref="StandardBusinessDocumentHeader" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
</xs:complexType>

[Interestingly it actually does use xsd:any !!

It is just as well it isn't

<xs:complexType name="StandardBusinessDocument">
<xs:sequence>
<xs:element ref="StandardBusinessDocumentHeader" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>

or I'd be tempted to use it for the purpose for which it wasn't designed
:-) ]

What I have meant is the use of the same sort of schema but one
custom made (in the absence of a standardised alternative) along
similar lines.

I still think it might be nice later to have something to go in
between the StandardBusinessDocument and a group of documents
with a schema having something like

<xs:complexType name="StandardBusinessDocumentGroup">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>

Ah, sigh!!

This would use xsd:any so it wouldn't be UBL NDR compliant
(unless an exception is made for the like of what we have in the
SBDH schema).

Instead, as I've tried to emphasise all along, it is necessary to
create one's own document top level element and a schema
to go with it in order to tag together multiple documents or
a document and extra data from another namespace.

Though this is presently a not exactly satisfactory state of
affairs, it seems the only way to avoid xsd:any in the
schemas of the documents themselves while keeping to
the use of XML, avoiding binary documents which might not be
readable in years to come (the documents could be printed to
microfilm for a longer shelf-life).

Sorry

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 4:39 PM
Subject: [ubl-dev] Re: [ubl] Re: [ubl-dev] Treasury Tag Pattern: to 'glue'
two instances having different schemas


> Stephen:
>
> I think we are agreeing.
>
> Stephen Green wrote:
>
> >I'm not sure though what the problem difference is between a datatype
> >allowing any string (xsd:string) and one allowing any XML (xsd:any).
> >The latter is, after all, a structured form of the former with * more *
> >opportunity for control of form and of resuse. The string can be
constrained
> >by a pattern, etc and the XML by a schema. What really is the difference?
> >I'd say the XML was preferable to the string. After all, what is better
> >in a business message:
> >
> >
> DN - the string in the code represented a value for one of the possible
> many SBDH values.  I was only comparing it to the element name value
> converted to a string to illustrate the requirement placed on coders to
> handle large lists of SBDH values when parsing XML.  It shows that the
> SBDH methodology is flawed.
>
> >or
> ><![CDATA[ <Order
> >xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0"
> >
> >
> >><ID>123</ID>...</Order> ]]>
> >>
> >>
> >
> >  = xsd:string content
> >
> >The latter is harder, more expensive to process and could hide all sorts
of
> >things
> >and is ignored by validating parsers, ... the objections could go on.
> >
> >
> DN - Agree - the latter is dangerous since you have no idea what goes on
> in that CDATA section. Concur that is should be avoided.
>
> >
> >
> >
> >
> >I'd regard xsd:string as more likely to lead to the inclusion
> >of hundreds of Mb of CDATA (see above).
> >
> >
> Dn - String (specifically normalized string) can be constrained with
> maxLength and minLegth attributes in the schema so this is not an issue.
>
> >Are we really sure we are doing the right thing here?
> >
> >
> DN - probably not.  I think this requires a more holistic approach that
> takes into account the messaging system, final processing requirements
> and more.  UBL has done a great job of getting 95% of the way, but this
> may be a specific set of circumstances that needs to frame the problem
> in a larger scope.
>
> >Finally, xsd:any allows control of namespaces through ##any etc
> >so it isn't as 'bad' as many make out. It really is just an XML datatype
> >and even mainstream databases, Java SDK, etc are starting to incorporate
> >the XML datatype at last. I admit it does need risk assessment though
> >so I'd rather not push this too far without accepting that a lot of
> >discussion
> >and plenty of foresight is necessary here.
> >
> >
> DN - Yes.  I am also aware of some of the recent support.  The main
> issue with "any" is that the sender may be under the impression that the
> receiver has read and understood the entire content.  If the receiver
> has not written specific code to handle the content of any, then they
> will not have it at their disposal.  A generalized iterator() could
> handle the content and store it, but taking specific actions on an
> unknown structure has proven to be problematic at best.  Even something
> as mundane as namespaces may be duplicated with a parser defaulting to
> the innermost namespace within any hence confusing the issue more.
>
> Cheers!
>
> Duane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>