(In reply to comment #11)
> On Andreas' comments: I didn't realize that the spec says to initialize the
> "id" property to an initial value. Of course, it would make sense to use that
> instead of the foi:ptr. I am, however, concerned about the performance
> implications for a collision detection which I don't think should be ignored.
Well, what I'm personally a bit concerned about is the case where you have:
1) auto-generated ids by the 'main' stylesheet
2) additional auto-generated ids by the 'pre-processing' stylesheet
Since we have two passes, are we still 100% certain that the XSLT processor will always return unique values that are used nowhere as an id elsewhere in the document?
For explicit ids, this problem would also exist, but AFAIK, no one specifies explicit ids like "N897654", which is a format returned by some generate-id() implementations.
If the answer to my above question is yes, then there is no real overhead (on the FOP-side) involved for collision-detection, since the XSLT processor will take care of that (or even the XML parser: Is 'id' not a standard XML attribute? Or does it have nothing to do with the standard 'id()' XPath function? I'd have to check in the respective specifications to be sure...)
> Also, the area tree and AT XML will increase in size of all elements have IDs.
True, but then again, doesn't the foi:ptr also have to be carried through to the area tree or IF?
Maybe to address this concern, we could limit the case where the ids are actually auto-generated to this one: when accessibility is enabled. IOW, if and when it is needed (not default behavior).
> BTW, Andreas' proposal for adding the IDs is not entirely correct. Not all FO
> element take an "id" property.
Again, very true, but we do implement getId() in FObj. That currently means that, although the property may not apply to a given element, like fo:declarations, as long as the Java object extends FObj, the id property will be bound and available if it is specified.
Checking closer, Declarations.java overrides bind() rather than relying on the superclass implementation. Removing that empty implementation would be enough to make it work.
Not 100% compliant, but it seems like this actually may have added value here.
> Maybe this should be done inside the FO tree instead of the addPtr.xsl.
What I was thinking indeed. Something like a dedicated IDPropertyMaker that extends StringProperty.Maker, and would offer an implementation for make(FObj, PropertyList) that returns a 'proper' initial value. I once implemented it as such (and committed it, but it was a bit too quick and caused other issues, so it was reverted almost immediately)
Downside is that, if we implement it like that in the FO tree, it would also be necessary to implement the b) part in my earlier response, as the ids will never be available in the raw FO source, so reduceFOTree.xsl would not yet 'see' them (unless they would be added by a pre-processing stylesheet, like Jost proposes)