[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: [ubl-dev] Treasury Tag Pattern: to 'glue' two instanceshaving 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]