[ 
https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473686
 ] 

Kelvin Goodson commented on TUSCANY-1088:
-----------------------------------------

I just committed your patch for TUSCANY-713 and noticed that the patch for this 
JIRA includes the fix for TUSCANY-713, so I have 2 comments.
The first is to replicate the comment I erroneously put on TUSCANY-713 which is 
that, given the discussion above, the TODO should indicate that there is some 
thinking to be done about the restoration of options.  I have altered the 
comment in the committing of TUSCANY-713
The second is to request that we try to keep patches isolated,  and if JIRAs 
have dependencies on one another, then we make this explicit using the JIRA 
tooling,  and keep the patches non-overlapping.  I have attempted to apply the 
patch for this JIRA over the current trunk,  but now that the FIX for 713 is in 
place there are non-trivial conflicts in the doLoad method.  Could you resolve 
these please and resubmit the patch?  Thanks, Kelvin.

> SDO should tolerate malformed XML
> ---------------------------------
>
>                 Key: TUSCANY-1088
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1088
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SDO Implementation
>    Affects Versions: Java-SDO-Mx
>            Reporter: Kevin Williams
>         Assigned To: Kelvin Goodson
>             Fix For: Java-SDO-Mx
>
>         Attachments: FormTestCase.java, patch
>
>
> I had some off-line discussion with Frank and Yang.  Here is the summary:
> As an improvement to consumability, SDO should tolerate some malformed XML.  
> XML documents are often less than well-formed.  Rather than failing on 
> deserialization when a document does not completely conform to its schema, we 
> should consider making some assumptions and continuing on.  Some competitor 
> technologies do this today.
> Here's an example.  Say we have this schema:
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://QuickTest/HelloWorld";
>       xmlns:tns="http://QuickTest/HelloWorld";
>       xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>       elementFormDefault="qualified">
>       <xsd:element name="sayHello">
>               <xsd:complexType>
>                       <xsd:sequence>
>                               <xsd:element name="input1" nillable="true"
>                                       type="xsd:string" />
>                       </xsd:sequence>
>               </xsd:complexType>
>       </xsd:element>
> </xsd:schema>
> If we get an xml that looks like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <tns:sayHello xmlns:tns="http://QuickTest/HelloWorld";
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>       xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd ">
>       <input1>input1</input1>
> </tns:sayHello>
> then we will fail validating this since input1 isn't fully qualified.  Here's 
> the xml that would work:
> <?xml version="1.0" encoding="UTF-8"?>
> <tns:sayHello xmlns:tns="http://QuickTest/HelloWorld";
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>       xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd ">
>       <tns:input1>tns:input1</tns:input1>
> </tns:sayHello>
> Frank mentioned 2 potential approaches:
>   1. Read the element in as if it was an open content property. If you 
> reserialize it would be the same (still invalid).
>   2. If a property with the same name (but different namespace) exists, then 
> associate it with that. When you reserialize it will be then be correct.
> The later seems the best approach.
> Yang also contributed the following:
> It's friendly to tolerate if a user forgets to qualify a local element. 
> There're 3 scenarios may not have the same elementFormDefault="qualified" 
> enforcement policy. What do you think?
> 3-1.  <tns:sayHello xmlns:tns="http://QuickTest/HelloWorld";>
>               <input1>input1</input1>
>       </tns:sayHello>
> The author may have forgot to qualify "input1" element, although "input1" may 
> also be a global element without NameSpace.
> It's friendly to tolerate.
> 3-2.  <tns:sayHello xmlns:tns="http://QuickTest/HelloWorld"; 
> xmlns:onPurpose="differentNameSpace">
>               <onPurpose:input1>input1</onPurpose:input1>
>       </tns:sayHello>
> The author has qualified "input1" element; I'm not confident we should 
> tolerate.
> 3-3.  <tns:sayHello xmlns:tns="http://QuickTest/HelloWorld"; 
> xmlns="differentNameSpace"> <!-- xmlns= declares all unqualified 
> elements/attributes under "differentNameSpace" -->
>               <input1>input1</input1>
>       </tns:sayHello>
> It's hard to tell if the author may have forgot to qualify "input1" element 
> or not.
> I bet on not. Should we tolerate?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to