Re: [xml] Potential wrong usage of xmlIsID() in tree.c



Hi,

On Tue, 2006-02-21 at 16:06 +0100, Kasimier Buchcik wrote:
Hi,

On Tue, 2006-02-21 at 08:56 -0500, Rob Richards wrote:
Kasimier Buchcik wrote:
As far as copy/import/adopt goes. I have found a couple of conflicting 
opinions for this. One is that the importing doc should determine if an 
attribute is added as an ID. The other (which is also how it is 
implemented in Xerces) is that an attribute should be copied/imported 
with the same ID-ness as in the source document. The latter would be in 
    

I agree with the latter mechanism. This looks like the only
sane/efficient mechanism to me currently (this is also the reason why
I'm not confident with automatic IDness detection).
  
I agree on the latter method as well. I do see some potential issues 
with the automatic detection after thinking about it more. From a purely 
DTD view, if the document is parsed without validation or attribute 
handling enabled, the current implementation will still create IDs 
modiying the tree. There is no indication in the document that
this was not desired. So the question comes to mind should IDs be 
created or not?

Ah, good point. I think it should not automatically create IDs in this
case, since we don't know if the attribute's element is valid, and thus
if the element/attribute is valid at that position of the tree. So we
could run into creating IDness for attributes which wouldn't become IDs
if processed by the validator.

I noticed that this is actually not an answer for your question :-) but
writing this down had the nice side-effect that I realized that the
current detection of IDness could mark attributes as IDs, even if they
are not IDs, but invalid attributes according to a DTD; i.e., to query
the DTD for an element/attribute combination is not enough to evaluate
if an attribute is an ID. So one could argue that the existing detection
is a bug.

To your question: Ah, good point :-) I think this should either be made
settable or be avoided. The latter being the solution I would prefer.

[...]

Regards,

Kasimier





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]