Schema restrictions on atomic datatypes causing "invalid" controls.

RESOLVED WONTFIX

Status

Core Graveyard
XForms
RESOLVED WONTFIX
10 years ago
2 years ago

People

(Reporter: Albert Holtsclaw, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
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.

Comment 1

10 years ago
Does it help if you use a better mime type for the .xsd files?
Currently those are text/plain, but try text/xml.
(Reporter)

Comment 2

10 years ago
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.

(Reporter)

Comment 3

10 years ago
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.  

Comment 4

10 years ago
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.

Comment 5

10 years ago
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
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.