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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev 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 havingdifferent schemas


Comments inline:

Stephen Green wrote:

>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.
DN - I find it troublesome that someone creates a single element that 
may have multiple names and no constraints on content (aka "any") and 
they call it a "standard".  What is that?  XML already states we can do 
this.  What is the standard?  Is it an enumerated list of names the 
element might have?  You cannot even express this properly using W3C 
Schema since it is far too ambiguous for anyone to ever process unless 
you make a huge "if.. else" construct:

// in java...
for (Int i = 0; i < SBDHNames.getLength(); i ++)
String SBDHName = myList.SBDHName[i];
Element foo = (Element) Document.getRootElement();
            if (foo.getElementName().equals( SBDHName)) {
                    // do something with it
// repeat as necessary....

Bah!!!  This is by far the worst idea ever.  IMO you should not use that.

>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.
DN - you can do that but the danger is that the receiver has to 
potentially handle all combinations.  You would have to have some out of 
bandwidth agreement with the receiver to recognize what ones they will 
process and which messages they will not.  This is usually the case 
anyways.  The receiver just writes a simple test to see if the one they 
handle is there and if it is not, they generate a message and send it 
back basically stating that "the message you sent is not supported".  
This is where WSDL is very useful since you can bind a service to a 
specific schema.  CPP can also do this although it is not as widely 

>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.
DN - agree with UBL thinking.  xs:any is harmful for interoperability 
since an instance may pass but could have anything in it.  It also 
leaves the door wide open for DoS attacks (a couple hundred mbs of CDATA 
could be added to messages and they would be processed).  I favour use 
of xs:import or make a UBL top level element that MAY contain 0..1 
instances of any number of other UBL schema fragments.  XoP is probably 
not the best solution here and you should not even consider using 
something as vague as the SBDH work IMO.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]