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

[Kasimier Buchcik <K Buchcik 4commerce de>]

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