Community
Participate
Working Groups
Eclipse 3.4 WTP 3.0 The DOM Level 1 Core specification: http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html Attr nodes can have two children nodes. Currently the WTP DOM Level 1 assumes that the attributes will not have any nodes, and that the value that is returned is the only value. However, this isn't correct according to the specification. Attr element in the DOM can have Text and/or EntityReference elements as children. The XSL Tools project needs this support for bug 242814. EntityReference nodes will need to have Entity nodes as specified by the spec. This allows WTP to not have to expand the entity but provide a reference back to the expanded version so that tooling can pull out the expanded version during processing. The entityreference would still allow the existing WTP behavior for editing purposes. An EntityReference is a Node object and inherits all of the Node object methods.
Dave, is it possible to create the Node objects when requested? The raw text is always available, so unless those Nodes are required to be constant in memory for some sort of event notification, it would take less memory to simply create them as needed.
(In reply to comment #1) > Dave, is it possible to create the Node objects when requested? The raw text > is always available, so unless those Nodes are required to be constant in > memory for some sort of event notification, it would take less memory to simply > create them as needed. Only a reference to the node needs to exist. The entity node itself can be created when the EntityReference nodes's get childNodes method is called, at that point the entity node is created. Entity reference nodes actually exist is multiple places. So an attribute value that looks like the following: <xsl:value-of select="translate($var1, &uppercase;, &lowercase;)"/> Would have the following nodes on the attribute: select (Attribute Node) text() = "translate($var1, " entityReference = &uppercase; text() = ", " entityReference = &lowercase; text() = ")" When the entityReference node is called that is when any child nodes would be created as read Only items. See the DOM Level 1 core specification for more detail. The important part for me is making sure I get the actual entity nodes so I can pull their value out from the content model that the DTD provides.
Some of this was already implemented with regards to 21440. The W3C DOM Conformance test suite tests for this support. If bug 214439 and bug 214440 are implemented it will take care of this request. Plus there is a full test suite that can be run to verify the conformance. Any possibility of getting me some help to actually look at getting WTP's DOM to pass the test suite. It'll take a lot of small patches, and verification of existing code.
I was planning to address bug 242814 in XSL Tools incubator this release, but it is really blocked by this bug until it is addressed at the WTP DOM. Any idea if this will be addressed in 3.1M2 or 3.1M3?
Not so far. I think this is one of the areas we were hoping to get help from you on.
(In reply to comment #5) > Not so far. I think this is one of the areas we were hoping to get help from > you on. > Well, the issue right now is that the WTP DOM really needs to address and pass the various DOM Level 1 compliance tests. I started that this work in Bug 214439 but when I started submitting patches it seemed to cause some alarm to the amount of changes that were happening. I have no problem working on this but it needs a level of committment from WTP committers to review it as well.
> I have no problem working on this but it needs a level of committment from > WTP committers to review it as well. I would be interested in seeing some of Dave's improvements move forward as well. Could we start by enumerating some less controversial changes? This one seems like a decent candidate.
(In reply to comment #7) > > I have no problem working on this but it needs a level of committment from > > WTP committers to review it as well. > > I would be interested in seeing some of Dave's improvements move forward as > well. Could we start by enumerating some less controversial changes? This one > seems like a decent candidate. > The issue with this one is the way the org.w3c.dom.Attr interface is implemented. Right now the assumption (which is wrong by WTP DOM), is that attributes don't have nodes. So the way the classes are extending the SSE Node class, is that none of the node related methods are inheritted from the class. The way the Node is implemented needs to be changed so that it correctly makes available to the lower classes the correct methods. According to the specification, Attributes can have Text and EntityReference nodes. So if you had something like the following: somevalue="attr &more text" You should get the following nodes: text() entityreference() text() So this relatively small change actually affects several classes. Which is where the panic came in, in the past. The DOM Level 1 conformance test, tests for this case, and WTP currently fails it.
> So this relatively small change actually affects several classes. Which is > where the panic came in, in the past. > The DOM Level 1 conformance test, tests for this case, and WTP currently > fails it. Are there any conformance test failures for which the fixes are less impactful? Could we start with those?
(In reply to comment #9) > > So this relatively small change actually affects several classes. Which is > > where the panic came in, in the past. > > The DOM Level 1 conformance test, tests for this case, and WTP currently > > fails it. > > Are there any conformance test failures for which the fixes are less impactful? > Could we start with those? > Yes..take a look at bug 214439 and bug 214440 for the original results, and a patch that allows the DOM test suite to be run from within the eclipse IDE, using the standard Junit framework, and plugin interface.
Created attachment 189453 [details] Make sure PreviousSibling, NextSibling, and ParentNode return null for Attributes Patch adds support to guarantee that Attributes always return null for the PreviousSibling, NextSibling, and ParentNode methods of DOM Level 1.
