[ https://issues.apache.org/jira/browse/XERCESJ-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786504#action_12786504
]
Ashitkin Alexander edited comment on XERCESJ-1392 at 12/6/09 11:02 AM:
-----------------------------------------------------------------------
Hi Michael, thanks for your response. I don't quite sure i've understood you correctly. If
points 1 and 2 are questions, then answers are:
1) i suppose the point 1 is regarding the error.xml instance. I don't see any reason to use
schemaLocation specified on the xs:import. From my point of view xs:import is an incapsulated
part of the schema and i only should provide valid schemaLocations either by external-schemaLocation
property, either by xsi:schemaLocation hint. I hope you agree the xsi:schemaLocation in error.xml
is absolutely valid and enough for validation. If you suppose i need to use schemaLocation
specified on the xs:import, please explain this.
2) i think the point is inside - out, should be : "Using the URI specified in the instance
as a schemaLocation in the xs:import" and if i understood right, this behaviour is just wrong.
if i have a set of schemas under the same namespace whose linked relatively, this behaviour
will break everything. In a case of honour-all-schemalocations this behaviour even more questionable.
was (Author: ashitkin.alexander):
Hi Michael, thanks for your response. I don't quite sure i've understood you correctly.
If points 1 and 2 are questions, then answers are:
1) i suppose the point 1 is regarding the error.xml instance. I don't see any reason to use
schemaLocation specified on the xs:import. From my point of view xs:import is an incapsulated
part of the schema and i only should provide valid schemaLocations either by external-schemaLocation
property, either by xsi:schemaLocation hint. I hope you agree the xsi:schemaLocation in error.xml
is absolutely valid and enough for validation. If you suppose i need to use schemaLocation
specified on the xs:import, please explain this.
2) from my point of view point is inside - out, should be : "Using the URI specified in the
instance as a schemaLocation in the xs:import" i think with behaviour is just wrong. if i
have a set of schemas under thesame namespace whish resolves relatively, it will break everything.
> Xerces breakes schema grammar with hints from instance xsi:schemaLocation
> -------------------------------------------------------------------------
>
> Key: XERCESJ-1392
> URL: https://issues.apache.org/jira/browse/XERCESJ-1392
> Project: Xerces2-J
> Issue Type: Bug
> Components: JAXP (javax.xml.validation)
> Affects Versions: 2.9.1
> Environment: Windows XP 2003
> Reporter: Ashitkin Alexander
> Attachments: XercesBug.zip
>
>
> Xerces trying to resolve xs:import in schema using relative paths from xsi:schemaLocation
hint. Thus, validation fails with a "Failed to read schema document" message.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786584#action_12786584
]
Mukul Gandhi commented on XERCESJ-1408:
---------------------------------------
as mentioned in the original problem description of this bug report, point 2) is now solved
and code for that has gone into SVN.
I've made some improvements to the kind of built in simple types (i.e, xs:anyAtomicType),
that can be handled by assertion facet (now much of the built in atomic types are recognized
by assertion facet implementation).
We still have to make corrections, to assign type to xpath2 variable, $value as anyAtomicType*.
This is still unclear to me, and I am doing some investigations to it. At presently within
Xerces, type of $value is xs:anyAtomicType. We need to make it a sequence of xs:anyAtomicType
(i.e, with cardinality "*").
It seems PsychoPath engine, currently doesn't support creating user defined variables ($value,
here), which can have types as "XDM sequence". I'll raise this query to the PsychoPath team,
so we can accomplish this within xerces. But this non-compliance looks, like a minor issue
to me, and we can improve this gradually.
Regards,
Mukul
> assertions facet validation rules, implementation improvements
> --------------------------------------------------------------
>
> Key: XERCESJ-1408
> URL: https://issues.apache.org/jira/browse/XERCESJ-1408
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.1 Datatypes
> Affects Versions: 2.10.0
> Reporter: Mukul Gandhi
> Assignee: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet
spec need to be implemented in entirety, in Xerces-J:
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
> Presently, the Xerces-J SVN code implements some parts of this spec.
> I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
> 1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
> (the present Xerces SVN implementation, doesn't strictly implements this. The current
implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable
$value, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1
schema on the simple type definition (which has assertion facets). We need to improve this,
as per the spec.)
> 2. There is no context item for the evaluation of the XPath expression. As a consequence
the expression '.', or any implicit or explicit reference to the context item, will raise
a dynamic error, which will cause the assertion to be treated as false. If an error is detected
statically, then the assertion violates the schema component constraint XPath Valid and causes
an error to be flagged in the schema.
> (the present implementation does cause a "xpath context" to exist, while evaluating the
xs:assertion facet XPath expressions. the current implementation doesn't flag an error to
the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression.
at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit
error for this.)
> To solve these issues, we also need to investigate the psychopath processor capabilities
in this regard.
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance,
to showcase the assertion facet implementation. But we can try to improve implementation of
these parts of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi reassigned XERCESJ-1408:
-------------------------------------
Assignee: Mukul Gandhi
> assertions facet validation rules, implementation improvements
> --------------------------------------------------------------
>
> Key: XERCESJ-1408
> URL: https://issues.apache.org/jira/browse/XERCESJ-1408
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.1 Datatypes
> Affects Versions: 2.10.0
> Reporter: Mukul Gandhi
> Assignee: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet
spec need to be implemented in entirety, in Xerces-J:
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
> Presently, the Xerces-J SVN code implements some parts of this spec.
> I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
> 1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
> (the present Xerces SVN implementation, doesn't strictly implements this. The current
implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable
$value, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1
schema on the simple type definition (which has assertion facets). We need to improve this,
as per the spec.)
> 2. There is no context item for the evaluation of the XPath expression. As a consequence
the expression '.', or any implicit or explicit reference to the context item, will raise
a dynamic error, which will cause the assertion to be treated as false. If an error is detected
statically, then the assertion violates the schema component constraint XPath Valid and causes
an error to be flagged in the schema.
> (the present implementation does cause a "xpath context" to exist, while evaluating the
xs:assertion facet XPath expressions. the current implementation doesn't flag an error to
the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression.
at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit
error for this.)
> To solve these issues, we also need to investigate the psychopath processor capabilities
in this regard.
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance,
to showcase the assertion facet implementation. But we can try to improve implementation of
these parts of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786504#action_12786504
]
Ashitkin Alexander commented on XERCESJ-1392:
---------------------------------------------
Hi Michael, thanks for your response. I don't quite sure i've understood you correctly. If
points 1 and 2 are questions, then answers are:
1) i suppose the point 1 is regarding the error.xml instance. I don't see any reason to use
schemaLocation specified on the xs:import. From my point of view xs:import is an incapsulated
part of the schema and i only should provide valid schemaLocations either by external-schemaLocation
property, either by xsi:schemaLocation hint. I hope you agree the xsi:schemaLocation in error.xml
is absolutely valid and enough for validation. If you suppose i need to use schemaLocation
specified on the xs:import, please explain this.
2) from my point of view point is inside - out, should be : "Using the URI specified in the
instance as a schemaLocation in the xs:import" i think with behaviour is just wrong. if i
have a set of schemas under thesame namespace whish resolves relatively, it will break everything.
> Xerces breakes schema grammar with hints from instance xsi:schemaLocation
> -------------------------------------------------------------------------
>
> Key: XERCESJ-1392
> URL: https://issues.apache.org/jira/browse/XERCESJ-1392
> Project: Xerces2-J
> Issue Type: Bug
> Components: JAXP (javax.xml.validation)
> Affects Versions: 2.9.1
> Environment: Windows XP 2003
> Reporter: Ashitkin Alexander
> Attachments: XercesBug.zip
>
>
> Xerces trying to resolve xs:import in schema using relative paths from xsi:schemaLocation
hint. Thus, validation fails with a "Failed to read schema document" message.
--
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
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
This is a bug [1] that was fixed in Xerces-J back in 2007.
However, you are using Sun's implementation, not Apache Xerces-J. We ca=
nnot
do anything about the problem you're having with this implementation as=
we
have no influence over its codebase. You need to pursue this with the J=
DK
vendor if you want a fix there.
Thanks.,
[1] https://issues.apache.org/jira/browse/XERCESJ-977
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
sri kumar <sri_kumar_4u@yahoo.co.in> wrote on 12/03/2009 04:50:50 AM:
> Hello All,
>
> I got null pointer exception while executing doc =3D builder.parse
(xmlDataFile);
>
> There were few entities in the XML data file. On removing a
> particular entity, i was able to parse the file successfully
>
> The entity was some thing like this
>
> <!ENTITY SAMPLE.TIF SYSTEM "SAMPLE.TIF" NDATA TIF>
>
> What could be the reason?
>
> Here is the code:
>
> DocumentBuilderFactory aFactory =3D DocumentBuilderFactory.newInstanc=
e();
> aFactory.setValidating(false);
> aFactory.setFeature("http://xml.org/sax/features/namespaces", false);=
> aFactory.setFeature("http://apache.org/xml/features/validation/schema=
> ", false);
> aFactory.setIgnoringComments(true);
> builder =3D aFactory.newDocumentBuilder();
> doc =3D builder.parse(xmlDataFile);
>
>
>
> This is the trace:
>
> at
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.setChunkI=
ndex
> (DeferredDocumentImpl.java:1944)
> at
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.appendChi=
ld
> (DeferredDocumentImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characte=
rs
> (AbstractDOMParser.java:1191)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.character=
s
> (XMLDTDValidator.java:862)
> at
>
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.=
scanDocument
> (XMLDocumentFragmentScannerImpl.java:463)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:807)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:737)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:107)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse
> (DOMParser.java:225)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse
> (DocumentBuilderImpl.java:283)
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:180)
> at XMLParser.Parse(XMLParser.java:89)
> at Main.main(Main.java:116)
>
>
>
> 89 line number points to -> doc =3D builder.parse(xmlDataFile);=
Hello All,
I got null pointer exception while executing doc = builder.parse(xmlDataFile);
There were few entities in the XML data file. On removing a particular entity, i was able
to parse the file successfully
The entity was some thing like this
<!ENTITY SAMPLE.TIF SYSTEM "SAMPLE.TIF" NDATA TIF>
What could be the reason?
Here is the code:
DocumentBuilderFactory aFactory = DocumentBuilderFactory.newInstance();
aFactory.setValidating(false);
aFactory.setFeature("http://xml.org/sax/features/namespaces", false);
aFactory.setFeature("http://apache.org/xml/features/validation/schema", false);
aFactory.setIgnoringComments(true);
builder = aFactory.newDocumentBuilder();
doc = builder.parse(xmlDataFile);
This is the trace:
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.setChunkIndex(DeferredDocumentImpl.java:1944)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.appendChild(DeferredDocumentImpl.java:644)
at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(AbstractDOMParser.java:1191)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.characters(XMLDTDValidator.java:862)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:463)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:180)
at XMLParser.Parse(XMLParser.java:89)
at Main.main(Main.java:116)
89 line number points to -> doc = builder.parse(xmlDataFile);
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1407:
-----------------------------------
Attachment: RenameNodePatch.txt
One should not create patches while being in a rush.
While the latest patch is perfectly working, there were some artifacts which I cleaned up
with this one.
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: RenameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1407:
-----------------------------------
Attachment: (was: renameNodePatch.txt)
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: RenameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1301:
-----------------------------------
Attachment: WeakEventListenerPatch.txt
There was a bug in the implementation provided three years ago.
Due to a wrong increment the old code could cause an indexOutOffBounds Exception when renaming
nodes.
The new patch fixes this.
> EventListeners should be garbage collectable if the nodes the listeners are registered
upon are garbage collected
> -----------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1301
> URL: https://issues.apache.org/jira/browse/XERCESJ-1301
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 2 Events)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Priority: Trivial
> Attachments: WeakEventListenerPatch.txt
>
>
> EventListeners should be garbage collectable if the nodes the listeners are registered
upon are garbage collected
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1301:
-----------------------------------
Attachment: (was: WeakEventListenerPatch.txt)
> EventListeners should be garbage collectable if the nodes the listeners are registered
upon are garbage collected
> -----------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1301
> URL: https://issues.apache.org/jira/browse/XERCESJ-1301
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 2 Events)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Priority: Trivial
> Attachments: WeakEventListenerPatch.txt
>
>
> EventListeners should be garbage collectable if the nodes the listeners are registered
upon are garbage collected
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1407:
-----------------------------------
Attachment: (was: renameNodePatch.txt)
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: renameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1407:
-----------------------------------
Attachment: renameNodePatch.txt
This is a refined version doing a refined check whether an element can be renamed or needs
to be replaced.
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: renameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi updated XERCESJ-1408:
----------------------------------
Description:
I think, implementation of following section of XSD 1.1 data types, xs:assertion facet spec
need to be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
Presently, the Xerces-J SVN code implements some parts of this spec.
I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
(the present Xerces SVN implementation, doesn't strictly implements this. The current implementation,
assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $value, like
xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1 schema on the
simple type definition (which has assertion facets). We need to improve this, as per the spec.)
2. There is no context item for the evaluation of the XPath expression. As a consequence the
expression '.', or any implicit or explicit reference to the context item, will raise a dynamic
error, which will cause the assertion to be treated as false. If an error is detected statically,
then the assertion violates the schema component constraint XPath Valid and causes an error
to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluating the xs:assertion
facet XPath expressions. the current implementation doesn't flag an error to the user, if
an attempt is made to refer the expression '.' in assertion facet xpath expression. at least,
the assertion should evaluate to false, in this case, even if we don't flag an explicit error
for this.)
To solve these issues, we also need to investigate the psychopath processor capabilities in
this regard.
I think, for the XSD 1.1 preview implementation, we have good enough spec conformance, to
showcase the assertion facet implementation. But we can try to improve implementation of these
parts of the spec, at the earliest.
was:
I think, implementation of following section of XSD 1.1 data types, xs:assertion facet spec
need to be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
Presently, the Xerces-J SVN code implements some parts of this spec.
I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
(the present Xerces SVN implementation, doesn't strictly implements this. The current implementation,
assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $variable,
like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1 schema
on the simple type definition (which has assertion facets). We need to improve this, as per
the spec.)
2. There is no context item for the evaluation of the XPath expression. As a consequence the
expression '.', or any implicit or explicit reference to the context item, will raise a dynamic
error, which will cause the assertion to be treated as false. If an error is detected statically,
then the assertion violates the schema component constraint XPath Valid and causes an error
to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluating the xs:assertion
facet XPath expressions. the current implementation doesn't flag an error to the user, if
an attempt is made to refer the expression '.' in assertion facet xpath expression. at least,
the assertion should evaluate to false, in this case, even if we don't flag an explicit error
for this.)
To solve these issues, we also need to investigate the psychopath processor capabilities in
this regard.
I think, for the XSD 1.1 preview implementation, we have good enough spec conformance, to
showcase the assertion facet implementation. But we can try to improve implementation of these
parts of the spec, at the earliest.
making minor changes to the text of the problem description. $value was incorrectly mentioned
as $variable.
> assertions facet validation rules, implementation improvements
> --------------------------------------------------------------
>
> Key: XERCESJ-1408
> URL: https://issues.apache.org/jira/browse/XERCESJ-1408
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.1 Datatypes
> Affects Versions: 2.10.0
> Reporter: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet
spec need to be implemented in entirety, in Xerces-J:
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
> Presently, the Xerces-J SVN code implements some parts of this spec.
> I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
> 1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
> (the present Xerces SVN implementation, doesn't strictly implements this. The current
implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable
$value, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1
schema on the simple type definition (which has assertion facets). We need to improve this,
as per the spec.)
> 2. There is no context item for the evaluation of the XPath expression. As a consequence
the expression '.', or any implicit or explicit reference to the context item, will raise
a dynamic error, which will cause the assertion to be treated as false. If an error is detected
statically, then the assertion violates the schema component constraint XPath Valid and causes
an error to be flagged in the schema.
> (the present implementation does cause a "xpath context" to exist, while evaluating the
xs:assertion facet XPath expressions. the current implementation doesn't flag an error to
the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression.
at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit
error for this.)
> To solve these issues, we also need to investigate the psychopath processor capabilities
in this regard.
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance,
to showcase the assertion facet implementation. But we can try to improve implementation of
these parts of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1409:
-----------------------------------
Attachment: NodeListItemAccessPatch.txt
This patch additionally does some trivial index out of bounds checks.
> Optimization for random indexed access upon NodeList
> ----------------------------------------------------
>
> Key: XERCESJ-1409
> URL: https://issues.apache.org/jira/browse/XERCESJ-1409
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Priority: Minor
> Attachments: NodeListItemAccessPatch.txt
>
>
> Since Xerces stores children as a linked list, indexed access using NodeList.item(index)
has an execution time of O(n).
> That said, there are a few tweaks we still can do to keep absolute acces time low even
though we won't change it from O(n).
> Current Xerces imlementation already provides a simple optimization:
> Currently, the last retrieved child node and it's index is cached.
> Subsequent calls to ParentNode.nodeListItem start iterating the linked list of children
from this position.
> Assuming that quite a lot of random accesses are somewhat local to the last access point,
this is a reasonable optimization.
> However it improves nothing (but also does no harm) when accessing large child lists
in a random pattern.
> I suggest an additional tweak to be applied:
> The idea is to add a simple calculation to determine whether it might require less iterations
when iterating from the start or the end of the linked list instead of the last accessed ChildNode.
> While this imposes a (relatively small) constant overhead per call of item (a comparison,
an addition and a bitshift) this optimization should reduce the average number of linked list
iterations required for a true random access by a factor of two while ensuring that the number
of iterations will never exceed the number of iterations done by the current implementation.
> Please review attached Patch.
--
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
Optimization for random indexed access upon NodeList
----------------------------------------------------
Key: XERCESJ-1409
URL: https://issues.apache.org/jira/browse/XERCESJ-1409
Project: Xerces2-J
Issue Type: Improvement
Components: DOM (Level 3 Core)
Affects Versions: 2.9.1
Reporter: Ludger Bünger
Priority: Minor
Since Xerces stores children as a linked list, indexed access using NodeList.item(index) has
an execution time of O(n).
That said, there are a few tweaks we still can do to keep absolute acces time low even though
we won't change it from O(n).
Current Xerces imlementation already provides a simple optimization:
Currently, the last retrieved child node and it's index is cached.
Subsequent calls to ParentNode.nodeListItem start iterating the linked list of children from
this position.
Assuming that quite a lot of random accesses are somewhat local to the last access point,
this is a reasonable optimization.
However it improves nothing (but also does no harm) when accessing large child lists in a
random pattern.
I suggest an additional tweak to be applied:
The idea is to add a simple calculation to determine whether it might require less iterations
when iterating from the start or the end of the linked list instead of the last accessed ChildNode.
While this imposes a (relatively small) constant overhead per call of item (a comparison,
an addition and a bitshift) this optimization should reduce the average number of linked list
iterations required for a true random access by a factor of two while ensuring that the number
of iterations will never exceed the number of iterations done by the current implementation.
Please review attached Patch.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784744#action_12784744
]
Ludger Bünger commented on XERCESJ-1397:
----------------------------------------
Ok, I agree that backwards compatibility is important and leaving this the way it currently
is does no harm.
We should close the issue.
> After invoking mutating methods upon CharacterData, DOMCharacterDataModified events are
always thrown even if the content remains the same (i.e. no change happend)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1397
> URL: https://issues.apache.org/jira/browse/XERCESJ-1397
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 2 Events)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Attachments: DOMCharacterDataModifiedPatch.txt
>
>
> Invoking mutation methods upon the CharacterData interface (e.g. insertData, appendData,
setNodeValue) always causes a DOMCharacterDataModified event to be thrown, even if the underlying
character data remains the same (e.g. setting the same content twice).
> According to the DOM Level 2 specification (http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MutationEvent),
the DOMCharacterDataModified is to be "fired after CharacterData within a node has been modified".
> It is debatable whether setting the same content twice falls under "CharacterData within
a node has been modified" so i classified this issue as an improvement, not a bug.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi updated XERCESJ-1408:
----------------------------------
Summary: assertions facet validation rules, implementation improvements (was: assertions
facet validation rules, improvements)
some minor changes to the subject
> assertions facet validation rules, implementation improvements
> --------------------------------------------------------------
>
> Key: XERCESJ-1408
> URL: https://issues.apache.org/jira/browse/XERCESJ-1408
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.1 Datatypes
> Affects Versions: 2.10.0
> Reporter: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet
spec need to be implemented in entirety, in Xerces-J:
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
> Presently, the Xerces-J SVN code implements some parts of this spec.
> I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
> 1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
> (the present Xerces SVN implementation, doesn't strictly implements this. The current
implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable
$variable, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD
1.1 schema on the simple type definition (which has assertion facets). We need to improve
this, as per the spec.)
> 2. There is no context item for the evaluation of the XPath expression. As a consequence
the expression '.', or any implicit or explicit reference to the context item, will raise
a dynamic error, which will cause the assertion to be treated as false. If an error is detected
statically, then the assertion violates the schema component constraint XPath Valid and causes
an error to be flagged in the schema.
> (the present implementation does cause a "xpath context" to exist, while evaluating the
xs:assertion facet XPath expressions. the current implementation doesn't flag an error to
the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression.
at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit
error for this.)
> To solve these issues, we also need to investigate the psychopath processor capabilities
in this regard.
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance,
to showcase the assertion facet implementation. But we can try to improve implementation of
these parts of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi updated XERCESJ-1408:
----------------------------------
Description:
I think, implementation of following section of XSD 1.1 data types, xs:assertion facet spec
need to be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
Presently, the Xerces-J SVN code implements some parts of this spec.
I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
(the present Xerces SVN implementation, doesn't strictly implements this. The current implementation,
assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $variable,
like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1 schema
on the simple type definition (which has assertion facets). We need to improve this, as per
the spec.)
2. There is no context item for the evaluation of the XPath expression. As a consequence the
expression '.', or any implicit or explicit reference to the context item, will raise a dynamic
error, which will cause the assertion to be treated as false. If an error is detected statically,
then the assertion violates the schema component constraint XPath Valid and causes an error
to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluating the xs:assertion
facet XPath expressions. the current implementation doesn't flag an error to the user, if
an attempt is made to refer the expression '.' in assertion facet xpath expression. at least,
the assertion should evaluate to false, in this case, even if we don't flag an explicit error
for this.)
To solve these issues, we also need to investigate the psychopath processor capabilities in
this regard.
I think, for the XSD 1.1 preview implementation, we have good enough spec conformance, to
showcase the assertion facet implementation. But we can try to improve implementation of these
parts of the spec, at the earliest.
was:
Implementation of following section of XSD 1.1 data types, xs:assertion facet spec need to
be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
Presently, the Xerces SVN code implements some parts of this spec.
I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
(the present implement doesn't strictly implement this. The current implementation, assigns
specific "built in" XSD types to the xpath2 "dynamic context" variable $variable, like xs:string,
xs:date, etc depending the XSD type, that exists in the schema on the simple type definition.
We need to improve this, as per the spec.)
2. There is no context item for the evaluation of the XPath expression. As a consequence the
expression '.', or any implicit or explicit reference to the context item, will raise a dynamic
error, which will cause the assertion to be treated as false. If an error is detected statically,
then the assertion violates the schema component constraint XPath Valid and causes an error
to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluation the xs:assertion
facet XPath expressions. the current implementation doesn't flag an error to the user, if
an attempt is made to refer the expression '.' in assertion facet xpath expression. at least,
the assertion should evaluate to false, in this case, even if we don't flag an explicit error
for this.)
To solve these issues, we also need to investigate the psychopath processor capabilities in
this regard.
I think, for the XSD 1.1 preview release, we have good enough implementation, to showcase
the assertion facet implementation. But we can try to improve implementation of these parts
of the spec, at the earliest.
doing some minor improvements to the text, of the issue.
> assertions facet validation rules, improvements
> -----------------------------------------------
>
> Key: XERCESJ-1408
> URL: https://issues.apache.org/jira/browse/XERCESJ-1408
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.1 Datatypes
> Affects Versions: 2.10.0
> Reporter: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet
spec need to be implemented in entirety, in Xerces-J:
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
> Presently, the Xerces-J SVN code implements some parts of this spec.
> I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
> 1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
> (the present Xerces SVN implementation, doesn't strictly implements this. The current
implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable
$variable, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD
1.1 schema on the simple type definition (which has assertion facets). We need to improve
this, as per the spec.)
> 2. There is no context item for the evaluation of the XPath expression. As a consequence
the expression '.', or any implicit or explicit reference to the context item, will raise
a dynamic error, which will cause the assertion to be treated as false. If an error is detected
statically, then the assertion violates the schema component constraint XPath Valid and causes
an error to be flagged in the schema.
> (the present implementation does cause a "xpath context" to exist, while evaluating the
xs:assertion facet XPath expressions. the current implementation doesn't flag an error to
the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression.
at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit
error for this.)
> To solve these issues, we also need to investigate the psychopath processor capabilities
in this regard.
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance,
to showcase the assertion facet implementation. But we can try to improve implementation of
these parts of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784625#action_12784625
]
Michael Glavassevich commented on XERCESJ-1390:
-----------------------------------------------
FYI: We likely fixed the equivalent bug in Xerces-J 2.9.1. See XERCESJ-977. However the fix
here would in no way resolve the issue in the JDK since they ship their own fork of the codebase.
> NullPointerException while parsing document with XHTML entity resolver. "Random changes"
fix the error in the document.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1390
> URL: https://issues.apache.org/jira/browse/XERCESJ-1390
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Reporter: Yonas Jongkind
> Attachments: XercesNPX.zip
>
>
> See the attached test to reproduce the error. This is the output that I get from the
test.
> If I remove the XhtmlEntityResolver the test will pass. Also, the only difference between
the two XML files in the test is the addition of a comment.
> Java Home: C:\Program Files (x86)\Java\jre6
> Java Version: 1.6.0_14
> Parsing Works
> Parsing Fails
> Exception in thread "main" java.lang.NullPointerException
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.setChunkIndex(Unknown
Source)
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.appendChild(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at TestXercesParse.parse(TestXercesParse.java:41)
> at TestXercesParse.main(TestXercesParse.java:24)
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich resolved XERCESJ-1390.
-------------------------------------------
Resolution: Invalid
You are using Sun's implementation, not Apache Xerces-J. We cannot do anything about the
problem you're having as we have no influence over that codebase. You need to pursue this
with the JDK vendor if you want a fix there.
> NullPointerException while parsing document with XHTML entity resolver. "Random changes"
fix the error in the document.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1390
> URL: https://issues.apache.org/jira/browse/XERCESJ-1390
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Reporter: Yonas Jongkind
> Attachments: XercesNPX.zip
>
>
> See the attached test to reproduce the error. This is the output that I get from the
test.
> If I remove the XhtmlEntityResolver the test will pass. Also, the only difference between
the two XML files in the test is the addition of a comment.
> Java Home: C:\Program Files (x86)\Java\jre6
> Java Version: 1.6.0_14
> Parsing Works
> Parsing Fails
> Exception in thread "main" java.lang.NullPointerException
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.setChunkIndex(Unknown
Source)
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.appendChild(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at TestXercesParse.parse(TestXercesParse.java:41)
> at TestXercesParse.main(TestXercesParse.java:24)
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich updated XERCESJ-1390:
------------------------------------------
Component/s: DOM (Level 3 Core)
> NullPointerException while parsing document with XHTML entity resolver. "Random changes"
fix the error in the document.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1390
> URL: https://issues.apache.org/jira/browse/XERCESJ-1390
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Reporter: Yonas Jongkind
> Attachments: XercesNPX.zip
>
>
> See the attached test to reproduce the error. This is the output that I get from the
test.
> If I remove the XhtmlEntityResolver the test will pass. Also, the only difference between
the two XML files in the test is the addition of a comment.
> Java Home: C:\Program Files (x86)\Java\jre6
> Java Version: 1.6.0_14
> Parsing Works
> Parsing Fails
> Exception in thread "main" java.lang.NullPointerException
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.setChunkIndex(Unknown
Source)
> at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.appendChild(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.characters(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at TestXercesParse.parse(TestXercesParse.java:41)
> at TestXercesParse.main(TestXercesParse.java:24)
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784620#action_12784620
]
Michael Glavassevich commented on XERCESJ-1392:
-----------------------------------------------
A couple issues here:
1) Why we're using xsi:schemaLocation instead of the schemaLocation specified on the xs:import.
2) Using the base URI from the importing schema document for resolving the URI specified in
the instance.
I believe the 1st is at the discretion of the schema processor. The spec gives implementations
freedom on how they locate schema documents. The schemaLocation on an import is just a hint.
Changing this now might break users who rely on the current behaviour from Xerces.
The 2nd is clearly wrong. Should use the base URI from the instance for resolving URIs contained
within it.
> Xerces breakes schema grammar with hints from instance xsi:schemaLocation
> -------------------------------------------------------------------------
>
> Key: XERCESJ-1392
> URL: https://issues.apache.org/jira/browse/XERCESJ-1392
> Project: Xerces2-J
> Issue Type: Bug
> Components: JAXP (javax.xml.validation)
> Affects Versions: 2.9.1
> Environment: Windows XP 2003
> Reporter: Ashitkin Alexander
> Attachments: XercesBug.zip
>
>
> Xerces trying to resolve xs:import in schema using relative paths from xsi:schemaLocation
hint. Thus, validation fails with a "Failed to read schema document" message.
--
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
assertions facet validation rules, improvements
-----------------------------------------------
Key: XERCESJ-1408
URL: https://issues.apache.org/jira/browse/XERCESJ-1408
Project: Xerces2-J
Issue Type: Improvement
Components: XML Schema 1.1 Datatypes
Affects Versions: 2.10.0
Reporter: Mukul Gandhi
Implementation of following section of XSD 1.1 data types, xs:assertion facet spec need to
be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules
Presently, the Xerces SVN code implements some parts of this spec.
I find that following sections of the spec (quoted from the spec, itself), are not implemented
correctly in Xerces-J:
1. The in-scope variables in the static context is a set with a single member. The expanded
QName of that member has no namespace URI and has 'value' as the local name. The (static)
type of the member is anyAtomicType*.
(the present implement doesn't strictly implement this. The current implementation, assigns
specific "built in" XSD types to the xpath2 "dynamic context" variable $variable, like xs:string,
xs:date, etc depending the XSD type, that exists in the schema on the simple type definition.
We need to improve this, as per the spec.)
2. There is no context item for the evaluation of the XPath expression. As a consequence the
expression '.', or any implicit or explicit reference to the context item, will raise a dynamic
error, which will cause the assertion to be treated as false. If an error is detected statically,
then the assertion violates the schema component constraint XPath Valid and causes an error
to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluation the xs:assertion
facet XPath expressions. the current implementation doesn't flag an error to the user, if
an attempt is made to refer the expression '.' in assertion facet xpath expression. at least,
the assertion should evaluate to false, in this case, even if we don't flag an explicit error
for this.)
To solve these issues, we also need to investigate the psychopath processor capabilities in
this regard.
I think, for the XSD 1.1 preview release, we have good enough implementation, to showcase
the assertion facet implementation. But we can try to improve implementation of these parts
of the spec, at the earliest.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784615#action_12784615
]
Michael Glavassevich commented on XERCESJ-1397:
-----------------------------------------------
It's possible that applications are relying on the current behaviour. Think of the 'touch'
command in Unix. Doesn't change the contents but gets you a new modification timestamp. I
can imagine users depending on this (whether it's in the spirit of the spec or not) so not
sure we could make this change. I tend to err on the side of backwards compatibility for grey
areas.
> After invoking mutating methods upon CharacterData, DOMCharacterDataModified events are
always thrown even if the content remains the same (i.e. no change happend)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1397
> URL: https://issues.apache.org/jira/browse/XERCESJ-1397
> Project: Xerces2-J
> Issue Type: Improvement
> Components: DOM (Level 2 Events)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Attachments: DOMCharacterDataModifiedPatch.txt
>
>
> Invoking mutation methods upon the CharacterData interface (e.g. insertData, appendData,
setNodeValue) always causes a DOMCharacterDataModified event to be thrown, even if the underlying
character data remains the same (e.g. setting the same content twice).
> According to the DOM Level 2 specification (http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MutationEvent),
the DOMCharacterDataModified is to be "fired after CharacterData within a node has been modified".
> It is debatable whether setting the same content twice falls under "CharacterData within
a node has been modified" so i classified this issue as an improvement, not a bug.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich reassigned XERCESJ-1407:
---------------------------------------------
Assignee: Michael Glavassevich
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Attachments: renameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich resolved XERCESJ-1403.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.10.0
Thanks. I've committed a fix in SVN rev 885927.
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1403
> URL: https://issues.apache.org/jira/browse/XERCESJ-1403
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (HTML)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Priority: Minor
> Fix For: 2.10.0
>
>
> I do not know whether anyone is interested at all in Bugs for HTML DOM.
> Here is one that the FindBugs Tool (findbugs.sourceforge.org) found:
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String) in Line 845
> The solution is simple: add "throw" so I do not provide a patch this time.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich reassigned XERCESJ-1403:
---------------------------------------------
Assignee: Michael Glavassevich
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1403
> URL: https://issues.apache.org/jira/browse/XERCESJ-1403
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (HTML)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
>
> I do not know whether anyone is interested at all in Bugs for HTML DOM.
> Here is one that the FindBugs Tool (findbugs.sourceforge.org) found:
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String) in Line 845
> The solution is simple: add "throw" so I do not provide a patch this time.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich updated XERCESJ-1403:
------------------------------------------
Priority: Minor (was: Major)
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1403
> URL: https://issues.apache.org/jira/browse/XERCESJ-1403
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (HTML)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Assignee: Michael Glavassevich
> Priority: Minor
>
> I do not know whether anyone is interested at all in Bugs for HTML DOM.
> Here is one that the FindBugs Tool (findbugs.sourceforge.org) found:
> org.apache.dom.html.HTMLDocumentImpl.populateElementType(String, String) forgets to throw
new RuntimeException(String) in Line 845
> The solution is simple: add "throw" so I do not provide a patch this time.
--
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
renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
------------------------------------------------------------------------
Key: XERCESJ-1407
URL: https://issues.apache.org/jira/browse/XERCESJ-1407
Project: Xerces2-J
Issue Type: Bug
Components: DOM (Level 3 Core)
Affects Versions: 2.9.1
Reporter: Ludger Bünger
Attachments: renameNodePatch.txt
I stumbled across an issue when using the DOM Level 3 renameNode method but this issue is
actually more than only related to renameNode:
Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a node
would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
Depending on the ourcome of this, there are two issues:
Issue 1:
If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
Xerces should call document.createElement instead so the correct class will be instanciated.
Actually I think it is a general problem that xerces sometimes call node constructors hard
coded instead of using the document.create methods and suggest changing this.
Issue 2:
If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an internal
rename method will be called upon the element/attribute implementation and the same node object
will be returned.
This is fine for the standard implementation, however in sometimes wrong for the HTML and
WML DOM.
The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
In these cases, instead of calling the internal rename method, the element should be re-created
using the createElement method of it's document implementation.
The solution here is the same as for issue 1:
use the document.create methods for renaming an element.
However we need to query whether the used DOM implementation allows element instances to be
renamed (general XML) or not (HTML, WML).
Please find attached a patch that:
1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
2) queries whether a DOM implementation permits node renaming and if not, re-created elements
upon calling rename.
I attached a patch that fixes these two issues.
I'd be pleased if someone could review whether the proposed solution is ok.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludger Bünger updated XERCESJ-1407:
-----------------------------------
Attachment: renameNodePatch.txt
> renameNode creates wrong Node Implementation with PSVI, HTML and WML DOM
> ------------------------------------------------------------------------
>
> Key: XERCESJ-1407
> URL: https://issues.apache.org/jira/browse/XERCESJ-1407
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.9.1
> Reporter: Ludger Bünger
> Attachments: renameNodePatch.txt
>
>
> I stumbled across an issue when using the DOM Level 3 renameNode method but this issue
is actually more than only related to renameNode:
> Depending on parameters the DOM Level 3 renameNode method analyses whether renaming a
node would cause a change of node implementation type, i.e. whether an instance of ElementImpl
or AttributeImpl will be renamed such that it aquires a Namespace and thus needs to be converted
to their respective NS counterparts (ElementNSImpl, AttrNSImpl).
> Depending on the ourcome of this, there are two issues:
> Issue 1:
> If the to-be-renamed node not an NS aware type (i.e. ElementImpl or AttrImpl) and a namespace
shall be set, xerces instantiates a new ElementNSImpl/AttNSImpl by calling the class constructor
for these hardcoded.
> However, when using the PSVI-aware DOM, this is the wrong class type! It should be PSVIElementNSImpl
instead!
> Xerces should call document.createElement instead so the correct class will be instanciated.
> Actually I think it is a general problem that xerces sometimes call node constructors
hard coded instead of using the document.create methods and suggest changing this.
> Issue 2:
> If the to-be-renamed node is of an NS-implementation-type or the namespace is null, an
internal rename method will be called upon the element/attribute implementation and the same
node object will be returned.
> This is fine for the standard implementation, however in sometimes wrong for the HTML
and WML DOM.
> The HTML and WML-DOM use specific element implementation classes i.e. HTMLHeadingElementImpl
or HTMLParagraphElementImpl.
> In these cases, instead of calling the internal rename method, the element should be
re-created using the createElement method of it's document implementation.
> The solution here is the same as for issue 1:
> use the document.create methods for renaming an element.
> However we need to query whether the used DOM implementation allows element instances
to be renamed (general XML) or not (HTML, WML).
> Please find attached a patch that:
> 1) replaces every call to Node imlementation constructors (except instances of DocumentImpls)
by calling the respective document.create method
> 2) queries whether a DOM implementation permits node renaming and if not, re-created
elements upon calling rename.
> I attached a patch that fixes these two issues.
> I'd be pleased if someone could review whether the proposed solution is ok.
--
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
Content-type: text/plain; charset=US-ASCII Hi Mukul, Mukul Gandhi <mukulg@apache.org> wrote on 11/24/2009 11:37:31 PM: > Thanks, Michael. > > Wishing a great build for 2.10.0 release :) I hope so. They usually go smoothly. > On Wed, Nov 25, 2009 at 9:24 AM, Michael Glavassevich > <mrglavas@ca.ibm.com> wrote: > > Hi Mukul, > > > > We've made minor tweaks in the past as late as the date of the release, but > > generally those last couple days are spent updating the documentation, > > making other non-code changes and actually doing the build and testing on > > that build. We should probably leave 2 or 3 days for that though nothing is > > set in stone. > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: mrglavas@ca.ibm.com > > E-mail: mrglavas@apache.org > > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org > For additional commands, e-mail: j-dev-help@xerces.apache.org Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org
Thanks, Michael. Wishing a great build for 2.10.0 release :) On Wed, Nov 25, 2009 at 9:24 AM, Michael Glavassevich <mrglavas@ca.ibm.com> wrote: > Hi Mukul, > > We've made minor tweaks in the past as late as the date of the release, but > generally those last couple days are spent updating the documentation, > making other non-code changes and actually doing the build and testing on > that build. We should probably leave 2 or 3 days for that though nothing is > set in stone. > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrglavas@ca.ibm.com > E-mail: mrglavas@apache.org -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org For additional commands, e-mail: j-dev-help@xerces.apache.org
Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Mukul, We've made minor tweaks in the past as late as the date of the release,= but generally those last couple days are spent updating the documentation, making other non-code changes and actually doing the build and testing = on that build. We should probably leave 2 or 3 days for that though nothin= g is set in stone. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org Mukul Gandhi <mukulg@apache.org> wrote on 11/24/2009 09:12:43 PM: > Hi Michael, > The improvements that will go into Xerces-J 2.10.0 release, look > impressive :) > > I had a question, please. > > Keeping in mind the release date for Xerces-J 2.10.0 (which is Dec 18= > 09', I believe), what will be the cut off date, that any more code > improvements for 2.10.0 release can go into Xerces SVN? > > On Mon, Nov 23, 2009 at 12:30 AM, Michael Glavassevich > <mrglavas@ca.ibm.com> wrote: > > As you can probably tell by the number of JIRA notifications to the= mailing > > list today, I've been busy marking the resolved issues (I count 58 = so far) > > which are fixed and will be included in Xerces-J 2.10.0. This getsdisplayed > > in JIRA as a nice report [1] which users can browse through to figu= re out > > what we fixed / added in a particular release. If you fix something= for > > 2.10.0 remember to mark it in JIRA as such so it will get rolled in= to this > > release notes page. > > > > Thanks. > > > > [1] > > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=3D10520&styleName=3DHtml&version=3D12314400 > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: mrglavas@ca.ibm.com > > E-mail: mrglavas@apache.org > > > > -- > Regards, > Mukul Gandhi > > ---------------------------------------------------------------------= > To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org > For additional commands, e-mail: j-dev-help@xerces.apache.org=
Hi Michael, The improvements that will go into Xerces-J 2.10.0 release, look impressive :) I had a question, please. Keeping in mind the release date for Xerces-J 2.10.0 (which is Dec 18 09', I believe), what will be the cut off date, that any more code improvements for 2.10.0 release can go into Xerces SVN? On Mon, Nov 23, 2009 at 12:30 AM, Michael Glavassevich <mrglavas@ca.ibm.com> wrote: > As you can probably tell by the number of JIRA notifications to the mailing > list today, I've been busy marking the resolved issues (I count 58 so far) > which are fixed and will be included in Xerces-J 2.10.0. This gets displayed > in JIRA as a nice report [1] which users can browse through to figure out > what we fixed / added in a particular release. If you fix something for > 2.10.0 remember to mark it in JIRA as such so it will get rolled into this > release notes page. > > Thanks. > > [1] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10520&styleName=Html&version=12314400 > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrglavas@ca.ibm.com > E-mail: mrglavas@apache.org -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org For additional commands, e-mail: j-dev-help@xerces.apache.org
[ https://issues.apache.org/jira/browse/XERCESJ-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich resolved XERCESJ-1406.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.10.0
Implemented in SVN rev 883581.
> Performance: XMLSchemaValidator.findSchemaGrammar() called too often.
> ---------------------------------------------------------------------
>
> Key: XERCESJ-1406
> URL: https://issues.apache.org/jira/browse/XERCESJ-1406
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.0 Structures
> Affects Versions: 2.9.1
> Reporter: Michael Glavassevich
> Assignee: Michael Glavassevich
> Fix For: 2.10.0
>
>
> On every startElement() call we attempt to look-up a SchemaGrammar which is usually never
read. In the best case it's already in the XMLGrammarPool, but when we're processing local
elements with no namespace we're likely to end up calling the EntityResolver over and over
again (even when none is registered we always go through XMLEntityManager.resolveEntity()),
attempting to load an empty XMLInputSource with the schema loader and after all that returning
null back from the method. That's a lot of wasted time.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich updated XERCESJ-1406:
------------------------------------------
Description: On every startElement() call we attempt to look-up a SchemaGrammar which
is usually never read. In the best case it's already in the XMLGrammarPool, but when we're
processing local elements with no namespace we're likely to end up calling the EntityResolver
over and over again (even when none is registered we always go through XMLEntityManager.resolveEntity()),
attempting to load an empty XMLInputSource with the schema loader and after all that returning
null back from the method. That's a lot of wasted time. (was: On every startElement() call
we attempt to look-up a SchemaGrammar which is usually never read. In the best case it's
already in the XMLGrammarPool, but when we're processing a local elements with no namespace
we're likely to end up calling the EntityResolver over and over again (even when none is register
we always go through XMLEntityManager.resolveEntity()), attempting to load an empty XMLInputSource
with the schema loader and after all that returning null back from the method. That's a lot
of wasted time.)
> Performance: XMLSchemaValidator.findSchemaGrammar() called too often.
> ---------------------------------------------------------------------
>
> Key: XERCESJ-1406
> URL: https://issues.apache.org/jira/browse/XERCESJ-1406
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.0 Structures
> Affects Versions: 2.9.1
> Reporter: Michael Glavassevich
> Assignee: Michael Glavassevich
>
> On every startElement() call we attempt to look-up a SchemaGrammar which is usually never
read. In the best case it's already in the XMLGrammarPool, but when we're processing local
elements with no namespace we're likely to end up calling the EntityResolver over and over
again (even when none is registered we always go through XMLEntityManager.resolveEntity()),
attempting to load an empty XMLInputSource with the schema loader and after all that returning
null back from the method. That's a lot of wasted time.
--
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
Performance: XMLSchemaValidator.findSchemaGrammar() called too often.
---------------------------------------------------------------------
Key: XERCESJ-1406
URL: https://issues.apache.org/jira/browse/XERCESJ-1406
Project: Xerces2-J
Issue Type: Improvement
Components: XML Schema 1.0 Structures
Affects Versions: 2.9.1
Reporter: Michael Glavassevich
On every startElement() call we attempt to look-up a SchemaGrammar which is usually never
read. In the best case it's already in the XMLGrammarPool, but when we're processing a local
elements with no namespace we're likely to end up calling the EntityResolver over and over
again (even when none is register we always go through XMLEntityManager.resolveEntity()),
attempting to load an empty XMLInputSource with the schema loader and after all that returning
null back from the method. That's a lot of wasted time.
--
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
[ https://issues.apache.org/jira/browse/XERCESJ-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich reassigned XERCESJ-1406:
---------------------------------------------
Assignee: Michael Glavassevich
> Performance: XMLSchemaValidator.findSchemaGrammar() called too often.
> ---------------------------------------------------------------------
>
> Key: XERCESJ-1406
> URL: https://issues.apache.org/jira/browse/XERCESJ-1406
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.0 Structures
> Affects Versions: 2.9.1
> Reporter: Michael Glavassevich
> Assignee: Michael Glavassevich
>
> On every startElement() call we attempt to look-up a SchemaGrammar which is usually never
read. In the best case it's already in the XMLGrammarPool, but when we're processing a local
elements with no namespace we're likely to end up calling the EntityResolver over and over
again (even when none is register we always go through XMLEntityManager.resolveEntity()),
attempting to load an empty XMLInputSource with the schema loader and after all that returning
null back from the method. That's a lot of wasted time.
--
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
Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable As you can probably tell by the number of JIRA notifications to the mai= ling list today, I've been busy marking the resolved issues (I count 58 so f= ar) which are fixed and will be included in Xerces-J 2.10.0. This gets displayed in JIRA as a nice report [1] which users can browse through t= o figure out what we fixed / added in a particular release. If you fix something for 2.10.0 remember to mark it in JIRA as such so it will get= rolled into this release notes page. Thanks. [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=3D1052= 0&styleName=3DHtml&version=3D12314400 Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org=
[ https://issues.apache.org/jira/browse/XERCESJ-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich updated XERCESJ-1389:
------------------------------------------
Fix Version/s: 2.10.0
> RegEx matching: ranges not computed correctly in "ignore case" mode
> -------------------------------------------------------------------
>
> Key: XERCESJ-1389
> URL: https://issues.apache.org/jira/browse/XERCESJ-1389
> Project: Xerces2-J
> Issue Type: Bug
> Components: Other
> Affects Versions: 2.9.1
> Reporter: Radu Preotiuc-Pietro
> Assignee: Khaled Noaman
> Fix For: 2.10.0
>
>
> There are a couple of problems in interpreting character ranges in "case-insensitive"
mode.
> When doing range subtraction (or negation), all the case-variants of the subtracted characters
need to be considered. For example, "[^Q]" means, in case-insensitive mode, "any character
except 'q' or 'Q'" but the regex engine matches both 'q' and 'Q' in this example.
> Also, in case-insensitive mode, all character classes must stay the same, so for example
"\p{Lu}" would not match a lowercase letter, but the regex engine matches 'q'.
--
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