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

[Duane Nickull <dnickull@adobe.com>]

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