--- Comment #12 from Andreas L. Delmelle <>  2009-02-18 
11:28:58 PST ---
(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()

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, 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)

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to