You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org> on 2009/03/25 05:33:50 UTC
[jira] Resolved: (XERCESJ-1351) Type alternatives implementation
seems to be broken
[ https://issues.apache.org/jira/browse/XERCESJ-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Glavassevich resolved XERCESJ-1351.
-------------------------------------------
Resolution: Fixed
Hiranya, I just committed your revised patch to SVN. Looks great! Took me awhile to review given how large it was. :-)
I made a few minor tweaks to get it compiling with JDK 1.3. There was some code relying on auto-unboxing of a Double which had slipped in. Also decided not to commit the change to XSAttributeChecker which unconditionally uses the map for XML Schema 1.1 instead of making the decision based on the value of "fSchemaVersion". I guess this might have been added while you were debugging but we should be determining this based on the schema version.
> Type alternatives implementation seems to be broken
> ---------------------------------------------------
>
> Key: XERCESJ-1351
> URL: https://issues.apache.org/jira/browse/XERCESJ-1351
> Project: Xerces2-J
> Issue Type: Bug
> Components: XML Schema 1.1 Structures
> Affects Versions: 2.9.1
> Environment: Windows XP, JRE 1.5.0_15
> Reporter: Mukul Gandhi
> Assignee: Michael Glavassevich
> Attachments: type-alternatives-updat1.patch, type-alternatives.patch
>
>
> I am running the latest Xerces-J development code from SVN repository. I tried the following sample XML document, and the XML Schema document.
> XML document:
> <PERSON xsi:noNamespaceSchemaLocation="person.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <FNAME>Mukul</FNAME>
> <LNAME>Gandhi</LNAME>
> <DOB>1999-06-02</DOB>
> <ADDRESS type="short">my address</ADDRESS>
> </PERSON>
> Schema:
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> <xs:element name="PERSON" type="PersonType" />
> <xs:complexType name="PersonType">
> <xs:sequence>
> <xs:element name="FNAME" type="xs:string" />
> <xs:element name="LNAME" type="xs:string" />
> <xs:element name="DOB" type="xs:date" />
> <xs:element name="ADDRESS" type="LongAddress">
> <xs:alternative test="@type='short'" type="ShortAddress"/>
> <xs:alternative test="@type='long'" type="LongAddress"/>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="ShortAddress">
> <xs:simpleContent>
> <xs:extension base="shortString">
> <xs:attribute name="type" type="xs:string"/>
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
> <xs:simpleType name="shortString">
> <xs:restriction base="xs:string">
> <xs:minLength value="1" />
> <xs:maxLength value="50" />
> </xs:restriction>
> </xs:simpleType>
> <xs:complexType name="LongAddress">
> <xs:sequence>
> <xs:element name="street1" type="xs:string" />
> <xs:element name="street2" type="xs:string" minOccurs="0" />
> <xs:element name="city" type="xs:string" />
> <xs:element name="state" type="xs:string" />
> <xs:element name="pin" type="xs:string" />
> <xs:element name="country" type="xs:string" />
> </xs:sequence>
> <xs:attribute name="type" type="xs:string"/>
> </xs:complexType>
> </xs:schema>
> When I apply validation using the above examples, with Xerces, I get following errors:
> [Error] person.xsd:11:69: s4s-elt-must-match.1: The content of 'ADDRESS' must match (annotation?, (simpleType
> | complexType)?, alternative*, (unique | key | keyref)*)). A problem was found starting at: alternative.
> [Error] person.xml:5:45: cvc-complex-type.2.3: Element 'ADDRESS' cannot have character [children], because the
> type's content type is element-only.
> [Error] person.xml:5:45: cvc-complex-type.2.4.b: The content of element 'ADDRESS' is not complete. One of '{st
> reet1}' is expected.
> It seems to me, that type alternative support in Xerces is not working as expected.
> Some comments about the Java class, org.apache.xerces.impl.xpath.XPath20 (which I think is used by type alternatives)
> The method,
> public boolean evaluateNodeTest(QName element, XMLAttributes attributes)
> doesn't use the parameter, "element" anywhere in the method body.
> Please correct me, on any of the points I have mentioned.
--
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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: [jira] Resolved: (XERCESJ-1351) Type alternatives implementation
seems to be broken
Posted by Mukul Gandhi <ga...@gmail.com>.
Thanks, Hiranya.
Hoping for sure for further interaction with you and other Xerces members.
On Thu, Mar 26, 2009 at 5:39 PM, Hiranya Jayathilaka
<hi...@gmail.com> wrote:
> Hi Mukul,
>
> I agree with your observations. Please see my comments in-line.
>
> On Thu, Mar 26, 2009 at 12:17 PM, Mukul Gandhi <ga...@gmail.com>
> wrote:
>>
>> Hi Michael,
>> I did a quick testing of type alternatives with few simple
>> examples, and following are my findings:
>>
>> 1. xs:error is not implemented (as you wrote).
>>
>> 2. The constructor function pattern is not recognized (the production,
>> [18] ConstructorFunction ::= QName '(' SimpleValue ')' in the type
>> alternatives spec).
>> for e.g., the syntax <xs:alternative test="xs:integer(@xx) = 1"
>> type=".. gives a syntax error.
>
> In the previous version of the XML schema spec this particular production
> had some issues. It is now resolved in the latest version of the spec. So we
> need to make a few changes to the code so that this production is recognized
> by the parser. I'll start working on it very soon.
>>
>>
>> 3. Similarly, cast as QName in test=".. does not seem to evaluate
>> properly. Though the syntax seems to be recognized.
>
> Yes. Some of the casts are not yes supported. But all the obvious casts
> (ones that do not incur any data loss) should work fine. We currently use
> the validate method of XSSimpleType to perform casts which is not very
> accurate. We need to figure out a better way of doing this.
>>
>>
>> 4. error messages need to be improved. presently we get a stack trace
>> in many error situations. The line numbers of the errors are presently
>> not printed, in many situations.
>
> +1. I'll look into this.
>
>>
>>
>> But certainly, type alternatives support as of now is much better than
>> I last saw in SVN code. I would like to congratulate, Hiranya for
>> this.
>
> Thanks for the complements :)
>
>>
>>
>> I'll work with the XPath 2.0 processor you have pointed below. I hope
>> to spend some time in the coming days on assertions. I would write to
>> the list when I have something to present..
>
> Wish you all the very best. I'll give you all the support you need in
> achieving this.
>
> Thanks,
> Hiranya
>
>>
>>
>> On Thu, Mar 26, 2009 at 10:05 AM, Michael Glavassevich
>> <mr...@ca.ibm.com> wrote:
>> > I've found there's still some work to do. xs:error isn't supported yet
>> > as an
>> > alternative and it doesn't seem like the alternatives are being checked
>> > for
>> > correct derivation against the declared type yet. There's also the new
>> > mechanism for inheriting attributes [1] (interacts with type
>> > alternatives)
>> > which needs to be implemented. There might be a few other odds and ends.
>> > Testing should help discover them.
>>
>>
>> > Thought I'd mention to the list that there's an XPath 2.0 parser /
>> > evaluator
>> > [2] which was recently donated to Eclipse [3]. I think we may be able to
>> > use
>> > it for supporting assertions. I understand that it is schema-aware and
>> > is
>> > apparently able to work with Xerces' XSModel.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: [jira] Resolved: (XERCESJ-1351) Type alternatives implementation
seems to be broken
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Mukul,
I agree with your observations. Please see my comments in-line.
On Thu, Mar 26, 2009 at 12:17 PM, Mukul Gandhi <ga...@gmail.com>wrote:
> Hi Michael,
> I did a quick testing of type alternatives with few simple
> examples, and following are my findings:
>
> 1. xs:error is not implemented (as you wrote).
>
> 2. The constructor function pattern is not recognized (the production,
> [18] ConstructorFunction ::= QName '(' SimpleValue ')' in the type
> alternatives spec).
> for e.g., the syntax <xs:alternative test="xs:integer(@xx) = 1"
> type=".. gives a syntax error.
In the previous version of the XML schema spec this particular production
had some issues. It is now resolved in the latest version of the spec. So we
need to make a few changes to the code so that this production is recognized
by the parser. I'll start working on it very soon.
>
>
> 3. Similarly, cast as QName in test=".. does not seem to evaluate
> properly. Though the syntax seems to be recognized.
Yes. Some of the casts are not yes supported. But all the obvious casts
(ones that do not incur any data loss) should work fine. We currently use
the validate method of XSSimpleType to perform casts which is not very
accurate. We need to figure out a better way of doing this.
>
>
> 4. error messages need to be improved. presently we get a stack trace
> in many error situations. The line numbers of the errors are presently
> not printed, in many situations.
+1. I'll look into this.
>
> But certainly, type alternatives support as of now is much better than
> I last saw in SVN code. I would like to congratulate, Hiranya for
> this.
Thanks for the complements :)
>
>
> I'll work with the XPath 2.0 processor you have pointed below. I hope
> to spend some time in the coming days on assertions. I would write to
> the list when I have something to present..
Wish you all the very best. I'll give you all the support you need in
achieving this.
Thanks,
Hiranya
>
> On Thu, Mar 26, 2009 at 10:05 AM, Michael Glavassevich
> <mr...@ca.ibm.com> wrote:
> > I've found there's still some work to do. xs:error isn't supported yet as
> an
> > alternative and it doesn't seem like the alternatives are being checked
> for
> > correct derivation against the declared type yet. There's also the new
> > mechanism for inheriting attributes [1] (interacts with type
> alternatives)
> > which needs to be implemented. There might be a few other odds and ends.
> > Testing should help discover them.
>
>
> > Thought I'd mention to the list that there's an XPath 2.0 parser /
> evaluator
> > [2] which was recently donated to Eclipse [3]. I think we may be able to
> use
> > it for supporting assertions. I understand that it is schema-aware and is
> > apparently able to work with Xerces' XSModel.
>
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
Re: [jira] Resolved: (XERCESJ-1351) Type alternatives implementation
seems to be broken
Posted by Mukul Gandhi <ga...@gmail.com>.
Hi Michael,
I did a quick testing of type alternatives with few simple
examples, and following are my findings:
1. xs:error is not implemented (as you wrote).
2. The constructor function pattern is not recognized (the production,
[18] ConstructorFunction ::= QName '(' SimpleValue ')' in the type
alternatives spec).
for e.g., the syntax <xs:alternative test="xs:integer(@xx) = 1"
type=".. gives a syntax error.
3. Similarly, cast as QName in test=".. does not seem to evaluate
properly. Though the syntax seems to be recognized.
4. error messages need to be improved. presently we get a stack trace
in many error situations. The line numbers of the errors are presently
not printed, in many situations.
But certainly, type alternatives support as of now is much better than
I last saw in SVN code. I would like to congratulate, Hiranya for
this.
I'll work with the XPath 2.0 processor you have pointed below. I hope
to spend some time in the coming days on assertions. I would write to
the list when I have something to present..
On Thu, Mar 26, 2009 at 10:05 AM, Michael Glavassevich
<mr...@ca.ibm.com> wrote:
> I've found there's still some work to do. xs:error isn't supported yet as an
> alternative and it doesn't seem like the alternatives are being checked for
> correct derivation against the declared type yet. There's also the new
> mechanism for inheriting attributes [1] (interacts with type alternatives)
> which needs to be implemented. There might be a few other odds and ends.
> Testing should help discover them.
> Thought I'd mention to the list that there's an XPath 2.0 parser / evaluator
> [2] which was recently donated to Eclipse [3]. I think we may be able to use
> it for supporting assertions. I understand that it is schema-aware and is
> apparently able to work with Xerces' XSModel.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: [jira] Resolved: (XERCESJ-1351) Type alternatives implementation seems
to be broken
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Mukul,
Mukul Gandhi <ga...@gmail.com> wrote on 03/25/2009 05:30:05 AM:
> I just downloaded the latest Xerces code from SVN repository after
> reading this note. All has just compiled fine.
>
> I hope the type alternatives implementation now really works fine :)
> I'll do some testing of type alternatives from user's perspective and
> will share my experiences.
I've found there's still some work to do. xs:error isn't supported yet as
an alternative and it doesn't seem like the alternatives are being checked
for correct derivation against the declared type yet. There's also the new
mechanism for inheriting attributes [1] (interacts with type alternatives)
which needs to be implemented. There might be a few other odds and ends.
Testing should help discover them.
> I am still trying to complete assertions implementation. Will try to
> devote some time on that as well.
Great. We appreciate the help.
Thought I'd mention to the list that there's an XPath 2.0 parser /
evaluator [2] which was recently donated to Eclipse [3]. I think we may be
able to use it for supporting assertions. I understand that it is
schema-aware and is apparently able to work with Xerces' XSModel.
> On Wed, Mar 25, 2009 at 10:03 AM, Michael Glavassevich (JIRA)
> <xe...@xml.apache.org> wrote:
> >
> > [ https://issues.apache.org/jira/browse/XERCESJ-1351?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Michael Glavassevich resolved XERCESJ-1351.
> > -------------------------------------------
> >
> > Resolution: Fixed
> >
> > Hiranya, I just committed your revised patch to SVN. Looks great!
> Took me awhile to review given how large it was. :-)
> >
> > I made a few minor tweaks to get it compiling with JDK 1.3. There
> was some code relying on auto-unboxing of a Double which had slipped
> in. Also decided not to commit the change to XSAttributeChecker
> which unconditionally uses the map for XML Schema 1.1 instead of
> making the decision based on the value of "fSchemaVersion". I guess
> this might have been added while you were debugging but we should be
> determining this based on the schema version.
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
[1]
http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/#Inherited_attributes
[2]
http://intellectualcramps.blogspot.com/2009/02/xpath-20-evaluation-with-psychopath.html
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=226245
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: [jira] Resolved: (XERCESJ-1351) Type alternatives implementation
seems to be broken
Posted by Mukul Gandhi <ga...@gmail.com>.
I just downloaded the latest Xerces code from SVN repository after
reading this note. All has just compiled fine.
I hope the type alternatives implementation now really works fine :)
I'll do some testing of type alternatives from user's perspective and
will share my experiences.
I am still trying to complete assertions implementation. Will try to
devote some time on that as well.
On Wed, Mar 25, 2009 at 10:03 AM, Michael Glavassevich (JIRA)
<xe...@xml.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/XERCESJ-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Glavassevich resolved XERCESJ-1351.
> -------------------------------------------
>
> Resolution: Fixed
>
> Hiranya, I just committed your revised patch to SVN. Looks great! Took me awhile to review given how large it was. :-)
>
> I made a few minor tweaks to get it compiling with JDK 1.3. There was some code relying on auto-unboxing of a Double which had slipped in. Also decided not to commit the change to XSAttributeChecker which unconditionally uses the map for XML Schema 1.1 instead of making the decision based on the value of "fSchemaVersion". I guess this might have been added while you were debugging but we should be determining this based on the schema version.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org