You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Kevin Williams (JIRA)" <tu...@ws.apache.org> on 2007/02/02 06:38:05 UTC

[jira] Created: (TUSCANY-1088) SDO should tolerate malformed XML

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
             Fix For: Java-SDO-Mx


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.  It is not uncommon for XML documents to not be 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kelvin Goodson updated TUSCANY-1088:
------------------------------------

    Fix Version/s:     (was: Java-SDO-Mx)
                   Java-SDO-M3

> 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-M3
>
>         Attachments: FormTestCase.java, patch, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469844 ] 

Yang ZHONG commented on TUSCANY-1088:
-------------------------------------

Thanks to Ole Ersoy for pointing out EMF solution https://bugs.eclipse.org/bugs/show_bug.cgi?id=166127

More requirements have been requested, scuh as attribute form tolerance in addition to element, and tolerance of form which should have been unqualified.


To summarize form tolerance discussions on the thread, there're two types: element and attribute. Each has two categories: missing prefix and extra prefix. Each of which has several tolerance levels. I've asked EMF to accommodate them such as to provide a (XMLResource) option and support a (System) property for default value.


Both element's and attribute's form is either qualified or unqualified.

For element/attribute of qualified form, prefix may be missing. For unqualified form, extra prefix may be used. It's user-friendly to optionally tolerate them. Option level can range from zero tolerance to a high one, and the default value can be different for deployment.

Here's 3 scenarios for qualified form. The prefix missing examples illustrate element, however they also apply to attribute.

Missing 3-1.	<tns:sayHello xmlns:tns="http://QuickTest/HelloWorld">
			<input1>...</input1>	<!-- should have been tns:input1 -->
		</tns:sayHello>
Tolerance level 1 LaxForm_NO_DefaultNS_NoGlobal(1): tolerate if no "input1" global element without NameSpace.
Tolerance level 2 LaxForm_NO_DefaultNS(2): tolerate no matter there's a "input1" global element or not

Missing 3-2.	<tns:sayHello xmlns:tns="http://QuickTest/HelloWorld" xmlns:onPurpose="differentNameSpace">
			<onPurpose:input1>...</onPurpose:input1>	<!-- should have been tns:input1 -->
		</tns:sayHello>
No tolerance IMHO.

Missing 3-3.	<tns:sayHello xmlns:tns="http://QuickTest/HelloWorld" xmlns="differentNameSpace">	<!-- xmlns= declares all unqualified elements/attributes under "differentNameSpace" -->
			<input1>...</input1>	<!-- should have been tns:input1 -->
		</tns:sayHello>
Tolerance level 3 LaxForm_DefaultNS_NoGlobal(3): tolerate if no "input1" global element under "differentNameSpace".
Tolerance level 4 LaxForm_DefaultNS(4): tolerate no matter there's a "input1" global element or not

Here's 3 scenarios for unqualified form. The extra-prefix examples illustrate element, however they also apply to attribute.

Extra 3-1.	<tns:sayHello xmlns:tns="http://QuickTest/HelloWorld">
			<tns:input1>...</tns:input1>	<!-- should have been <input1> -->
		</tns:sayHello>
Tolerance level 1 LaxForm_NO_DefaultNS_NoGlobal(1): tolerate if no "input1" global element under "http://QuickTest/HelloWorld".
Tolerance level 2 LaxForm_NO_DefaultNS(2): tolerate no matter there's a "input1" global element or not

Extra 3-2.	<tns:sayHello xmlns:tns="http://QuickTest/HelloWorld" xmlns:onPurpose="http://QuickTest/HelloWorld">
			<onPurpose:input1>...</onPurpose:input1>	<!-- should have been <input1> -->
		</tns:sayHello>
No tolerance IMHO.

Extra 3-3.	<sayHello xmlns="http://QuickTest/HelloWorld">	<!-- xmlns= declares all unqualified elements/attributes under "http://QuickTest/HelloWorld" -->
			<input1>...</input1>	<!-- should have been <input1 xmlns=""> -->
		</sayHello>
Tolerance level 3 LaxForm_DefaultNS_NoGlobal(3): tolerate if no "input1" global element under "http://QuickTest/HelloWorld".
Tolerance level 4 LaxForm_DefaultNS(4): tolerate no matter there's a "input1" global element or not

Assuming ELEMENT = 0, ATTRIBUTE = 8, MISSING = 0, EXTRA = 4, (XMLResource.)OPTION_LAX_FORM_PROCESSING default value can be IMHO:

LaxForm_NO_DefaultNS<<ELEMENT<<MISSING | LaxForm_DefaultNS<<ELEMENT<<EXTRA | LaxForm_NO_DefaultNS<<ATTRIBUTE<<MISSING | LaxForm_DefaultNS<<ATTRIBUTE<<EXTRA

unless set by (System) property XML.load.form.lax

> 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
>             Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473434 ] 

Yang ZHONG commented on TUSCANY-1088:
-------------------------------------

Yes, my intention to leave that as a TODO.

doLoad takes options from user, modifies options, calls super.doLoad. In theory, it'd better restore the options since user may reuse the options for other purpose, unless we document the options may be altered.

However, we also have the intention to keep implementation as simple as possible. I'm not 100% sure restoring options is a requirement hard enough to complicate code, neither am I 100% sure I should silently ignore the issue.

So, I left a TODO :-) It also applies to http://issues.apache.org/jira/browse/TUSCANY-713

> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Assigned: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kelvin Goodson reassigned TUSCANY-1088:
---------------------------------------

    Assignee: Kelvin Goodson

> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yang ZHONG updated TUSCANY-1088:
--------------------------------

    Attachment: patch

New patch rebasing
    http://issues.apache.org/jira/browse/TUSCANY-713

> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
    [ 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469879 ] 

Yang ZHONG commented on TUSCANY-1088:
-------------------------------------

Right now EMF patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=166127
is only available in EMF 2.3 requiring JDK 5.

> 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
>             Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Resolved: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kelvin Goodson resolved TUSCANY-1088.
-------------------------------------

    Resolution: Fixed

committed Yang's patch at revision 509168  -- Default behaviour is now to tolerate bad XML unless disabled by provision of options using the SDOUtil.XML_LOAD_LaxForm (or by the system property XML.load.form.lax -- not tested in this patch)

> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470350 ] 

Yang ZHONG commented on TUSCANY-1088:
-------------------------------------

Will back-port EMF patch to Tuscany which bases on EMF 2.2.

Propose XML load option SDOUtil.XML_LOAD_LaxForm (convention from http://issues.apache.org/jira/browse/TUSCANY-928).
The default value is to tolerate malformed XML confused by NameSpaces.

> 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
>             Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Yang ZHONG (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yang ZHONG updated TUSCANY-1088:
--------------------------------

    Attachment: FormTestCase.java
                patch

The attached patch has passed all build tests.

> 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
>             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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: [jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by Ole Ersoy <ol...@yahoo.com>.
Hi,

Ed Merks and I did some work on this (Mostly Ed :-) ).
I skimmed the JIRA briefly, and I think this applies
here:

See 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=166127

Here's a brief summary:


Case1:
The element is supposed to be namespaced,
but is not.

Case2:
The element is namespaced, but should not be.

Case3:
The element is namespaced, but the namespace
is different from the namespace that the element
is supposed to have per the schema definition.

The redesigne of BasicExtendedMetaData supports cases 

1 & 2

with a single switch.


Hopefully the new design of the 
BasicExtendedMetaData applies to this TUSCANY-1088

Cheers,
- Ole



--- "Kevin Williams (JIRA)"
<tu...@ws.apache.org> wrote:

> 
>      [
>
https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> 
> Kevin Williams updated TUSCANY-1088:
> ------------------------------------
> 
>     Description: 
> 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?
> 
> 
> 
> 
> 
> 
> 
>   was:
> 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.  It is not uncommon for
> XML documents to not be 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" 
=== message truncated ===



 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kevin Williams (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Williams updated TUSCANY-1088:
------------------------------------

    Description: 
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?







  was:
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.  It is not uncommon for XML documents to not be 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?








> 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
>             Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1088) SDO should tolerate malformed XML

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473410 ] 

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

Yang,
  I have tested the patch and it seems t work fine, thanks.  Just one query before I commit it.  There is a TODO you added in the doLoad method of SDOXMLResourceImpl to restore the options after the load.  Was it your intention to leave that as a TODO? If so,  can you explain the issue why it cant/needn't  be finished off please?

> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org