[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: Comments inline: Stephen Green wrote: >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. > > 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 supported. >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. Duane > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]