Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Wtp-wst-dev] Attribute getSpecified() method.
Thanks for the reply David. I'll check bug 152690 out. I'll also attach put the DOM W3C unit test bundle with bug 214439. That is the DOM W3C Test Suite with the necessary WTPTestDocumentBuilderFactory. 

Dave


David M Williams wrote:
Dave, some of this issue is documented in bug 152690 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=152690> ... and you might use it to document some of your findings/issues/patches/ 
As you can see, it's been an issue for a while :(
And, I guess, no one had a huge need to fix it.
So, it'd be great if you could.
It is true that the DOM API spec does not always lend itself to "source editing" and where we've seen that before, we try and document our best efforts in the JavaDoc ... there's one about "getNamespace" which of course I can't find now that 
I'm looking at it.
Not sure what you mean by "keep in sync", when you say "but now the issue is making sure this all stays in synch". But feel free to spell out specific's, or attach patches/JUnit's that show the issues, 
and it might help others of us give better feedback.





From: 	David Carver <d_a_carver@xxxxxxxxx>
To: "Web Standard Tools developer discussions." <wtp-wst-dev@xxxxxxxxxxx> 
Date: 	01/07/2008 12:41 AM
Subject: 	Re: [Wtp-wst-dev] Attribute getSpecified() method.


------------------------------------------------------------------------



Slight clarrification on getSpecified, the spec kinda of contradicts
itself a bit (surprise):

If this attribute was explicitly given a value in the original document,
this is |true|; otherwise, it is |false|. Note that the implementation
is in charge of this attribute, not the user. If the user changes the
value of the attribute (even if it ends up having the same value as the
default value) then the |specified| flag is automatically flipped to
|true|. To re-specify the attribute as the default value from the DTD,
the user must delete the attribute. The implementation will then make a
new attribute available with |specified| set to |false| and the default
value (if one exists).
In summary:

   * If the attribute has an assigned value in the document then
     |specified| is |true|, and the value is the assigned value.
   * If the attribute has no assigned value in the document and has a
     default value in the DTD, then |specified| is |false|, and the
     value is the default value in the DTD.
   * If the attribute has no assigned value in the document and has a
     value of #IMPLIED in the DTD, then the attribute does not appear
     in the structure model of the document.
   * If the attribute is not associated to any element (i.e. because it
     was just created or was obtained from some removal or cloning
     operation) |specified| is |true|.


Currently I believe our implementation on implements the first sentence
of the first paragraph.   I have implemented some of the other
fuctionality already for other tests, but now the issue is making sure
this all stays in synch, and the current approach only works for the
first case.


David Carver wrote:
> I've been going through the W3C DOM Test Suite, and running the DOM
> Level 1 XML core compliance tests against the WTP DOM
> implementation.   Several minor problems, I have been able to fix, but
> there is one that is driving me batty, and it has to do with the
> AttrImpl#getSpecified() method in
> org.eclipse.wst.xml.core.internal.document.
>
> The getSpecified() method is supposed to return the state of the
> attribute.  Whether it's value has been changed or not.   Currently
> this is done by checking to see if the ITextRegion valueRegion is not
> Null...if it is, it returns false if it isn't it doesn't. > Unfortunately, when running through the DOM doesn't appear to be 
> accurate half the time.
>
> When an attribute is removed, the valueRegion should also be
> removed.   If the attribute's value is set, the valueRegion should be
> updated as well.   My question is, when and where is the
> setValueRegion() method called.   As it isn't called within the
> AttrImpl, so I'm assuming this is something that was called from the
> StructuredDocument.    If so...then we have a timing issue going on
> between when this value is updated and when the DOM is being read for
> this value.
>
> Any ideas or thoughts would be appreciated it, this little switch is
> driving me up a wall.
>
> Dave
>
> _______________________________________________
> wtp-wst-dev mailing list
> wtp-wst-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev
>

_______________________________________________
wtp-wst-dev mailing list
wtp-wst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev

------------------------------------------------------------------------

_______________________________________________
wtp-wst-dev mailing list
wtp-wst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev

Back to the top