Re: DOM3 Events: range of DOMAttrModified modifications

On Dec 17, 2005, at 12:58 PM, Bjoern Hoehrmann wrote:

> Well, I'm just saying the language here is too vague (it does not
> specify whether changing the children of an Attr node also counts as
> "string based replacement of an Attr value" either, for example).

I was watching for that question, and did not see it appear at all in  
your prior message.  Perhaps I misread it somehow.  I believe  
changing the children of an Attr tends to change the string-based  
replacement of an Attr value (except in cases like text node  
normalization and/or entity reference removal where the actual string  
based replacement value resulting from the child nodes does not  
change even though the child nodes may have, which is not the same as  
replacing the Attr node itself, which is specifically described as a  
replacement operation).  It should, therefore, produce an Attr  
modified event if the string value of the attribute node changes as a  
result.

> It is true that in many environments changes to the prefix or whether
> the attribute value is specified or defaulted won't affect processing;
> that's a bit different for IDs though, I would not say that messing
> with those does not affect the "meaning" of a document. It might not
> be relevant to DOMAttrModified, but that's not clear at the moment.

Someone may pay attention to anything during processing.  There are  
other things you could do to a node such as even adding and removing  
mutation event handlers that clearly may change the processing but do  
not change the content or the meaning.

They do not reflect a real change in the meaning of the XML document  
that is being represented.  The identity is still the same and the  
value is still the same.  The prefix has always been syntactic sugar  
and does not change either the identity of the attribute or the value  
of the attribute.  The language seems quite clear to me on the topic  
that they would not generate attribute modified, because they do not  
change the string-based replacement of the value of the attribute.  I  
believe it is referred to in this way specifically to include changes  
caused to the string value by manipulating attribute child nodes but  
not other changes.

Setting or clearing whether it is an ID also does not change the  
content of the document, because it is not content of the document  
and does not affect how it will be serialized, so it can/will be lost  
during save-restore.  If a DOM implementation sets it correctly as it  
reads the document if it is aware of the proper DTD, etc., it may be  
useful to the application, but there is no guarantee it will, and the  
application can change it as well to try and fix it with the proper  
value if it seems important, but it is unreliable and clearly not  
actually document content (and sill not be saved) as the value of the  
attribute is.

I believe the intent was to only give events for specific significant  
changes in the actual document content.  To me, it is very clear that  
these do not change the meaning of the document in the slightest,  
even if they affect the processing by the application.  If you care  
about the actual prefix instead of the value of the namespaceURI or  
care whether the attribute value was specified or defaulted, I  
believe you are not following the XML specification properly.  This  
info was recorded in DOM so that it could be preserved when the  
document was serialized for the user to preserve a particular effect  
in the serialized form.  You are not supposed to care during ordinary  
processing.

As I read the paragraph you cite, it also excludes when you set the  
value and it becomes specified instead of unspecified.

I do not think it is unclear.  When the string value of the attribute  
changes, the event is generated.  I think I have said all I can say  
on the subject, unless you have a different question.

Ray

Received on Sunday, 18 December 2005 13:12:04 UTC