Closed Bug 424893 Opened 17 years ago Closed 9 years ago

Schema restrictions on atomic datatypes causing "invalid" controls.

Categories

(Core Graveyard :: XForms, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: albybum, Unassigned)

References

()

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 - XForms Plugin 0.8.4 My instance document links to the schema, and it all validates using DOMPrint. Instance data is being pulled into the XForm controls from the instance document for the control values. The controls are being rendered properly. However, the data validation (facets) from the schema (I think) are causing all kinds of weird behavior (flagging of controls as invalid - regardless of data, etc). And, the plugin is giving me no feedback. I know the schema is being used because I can change values (or force errors) and it affects the page. I know the instance document is being used because I can change values in it and they are being reflected in the page. And again, the instance document and schema validate, and I've tested the constraints using DomPrint. My sample files can be found at the following locations: http://www.albybum.net/temp/xforms/guitar/guitar.xhtml http://www.albybum.net/temp/xforms/guitar/guitar.xml http://www.albybum.net/temp/xforms/guitar/guitar.xsd An additional example of this problem (using a wikibooks example) is linked below: http://www.albybum.net/temp/xforms/bugzilla_demo/index.xhtml http://www.albybum.net/temp/xforms/bugzilla_demo/instance-data.xml http://www.albybum.net/temp/xforms/bugzilla_demo/data-types.xsd The restrictions placed on string and integer fields do not seem to be working at all, much less partially. Reproducible: Always Steps to Reproduce: 1. 2. 3. If the restrictions are supported in the plugin, the controls should not have been flagged as invalid when the controls contained valid values. If the restrictions are not currently supported in the plugin, the controls should not have defaulted to "invalid" status when attempting to do validation.
Does it help if you use a better mime type for the .xsd files? Currently those are text/plain, but try text/xml.
The problem persists locally or posted to the Web, apparently regardless of mime type. I associated xsd files with text/xml for the above-linked examples just to make sure.
It appears that "nested" type definitions are the only type definitions causing issues. The following code is an example of what I am calling a nested type definition. <xs:element name="foobar"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="8"/> </xs:restriction> </xs:simpleType> </xs:element> As opposed to a global type definition <xs:simpleType name="foo-type"> <xs:restriction base="xs:string"> <xs:minLength value="8"/> </xs:restriction> </xs:simpleType> <xs:element name="foobar" type="namespace:foo-type"> I can move the nested definitions from both the above examples into global type definitions, and the page works as expected. From what I can see, the only type definitions being enforced correctly are built-in base types and global types where an element uses type="" to refer to those types.
My findings are a little different than Albert Holtsclaw's findings. I am using firefox 2.0.0.14 with XForms 0.8.5. Some more details on this issue; maybe it helps a developer to identify and fix the issue. This works FINE (submission succeeds); the FIRST element does NOT have a restriction: <xs:element name="addresses"> <xs:complexType> <xs:sequence> <xs:element name="AddressID"/> <xs:element name="AddressName"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> This does NOT work (submission validation fails): <xs:element name="addresses"> <xs:complexType> <xs:sequence> <xs:element name="AddressID" type="AddressIDType"/> <xs:element name="AddressName"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:simpleType name="AddressIDType"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> So it has something to do with the first element.
I get the same results as Albert Holtsclaw did. When i moved my validation to a global type and set the type attribute on my element it worked how it should. Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 xforms 0.8.5
RIP xforms
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.