FOP 0.92beta throws a ValidationException if it finds that several XSL-FOs have the same ID and this, even when parameter "strict-validation" has been set to "false". Modular documents built using XInclude often contain duplicate IDs. For example, a modular document may contain three instances of the same table found at three different places in the document. There is no error that could be fixed in the source XML in such case. In all cases, IMHO, it does not make sense for a XSL-FO formatter such as FOP to completely stop working when it finds a validity error as benign as a duplicate ID. Changes made in FOP 0.92beta's src/java/org/apache/fop/fo/FObj.java: added test "if (getUserAgent().validateStrictly())". =============================================================== protected void checkId(String id) throws ValidationException { if (!id.equals("")) { Set idrefs = getFOEventHandler().getIDReferences(); if (!idrefs.contains(id)) { idrefs.add(id); } else { if (getUserAgent().validateStrictly()) { throw new ValidationException( "Property id \"" + id + "\" previously used; id values must be unique" + " in document.", locator); } } } } ===============================================================
If there are duplicate IDs in the XML and/or XSL then FOP doesnt care, but if they make it through to the generated XSL-FO then the XSL-FO is illegal because FOP will have no way of evaluating things like: 1) Basic Links that reference specific IDs 2) Page Citations that reference specific IDs. So this is not a benign error as you suggest.
(In reply to comment #1) > If there are duplicate IDs in the XML and/or XSL then FOP doesnt care, but if > they make it through to the generated XSL-FO then the XSL-FO is illegal > because FOP will have no way of evaluating things like: > > 1) Basic Links that reference specific IDs > 2) Page Citations that reference specific IDs. > > So this is not a benign error as you suggest. I'm sorry but I don't agree. I've tested that with my trivial patch. Instead of stopping its work abruptly, FOP works as expected by the user: it does its best efforts to output a usable PDF. 1) Basic Link points to the first occurrence of the multiply defined ID. 2) Page Citation contains the page number of the first occurrence of the multiply defined ID. I hate to say this to a developer because it generally upsets her/him, but the other XSL-FO formatters that I know do not stop doing their job simply because they have found multiply defined IDs in the XSL-FO document. I understand that you find my request terribly unclean, but please believe me, formatting modern, modular, perfectly sane, XML documents will often mean having to cope with illegal XSL-FOs due to multiply defined IDs. In all cases, thank you very much for your fine work on FOP 0.92beta. What a difference in quality with its previous incarnation (0.20.5)!
I always thought that uniqueness of ids is a constraint enforced by the XML Specification. XSL-FO being subject to the constraints defined in the XML Rec., it should report this as an error...? No, wait: the type of the id property should be <id>, which means, if you look at the Rec (5.11 Property Datatypes), that it should be an NCName that is unique... within the _stylesheet_? Other opinions?
I agree with Chris and Andreas. The XSL-FO spec is very clear about the requirement of uniqueness of the values of the id attribute. You could obtain a valid FO file by not propagating id attributes from your XML file to the FO file. OTOH, I agree that it is a feature that we may choose to suppress under lax validation, because the FO file is still quite renderable, apart from linking to internal destinations. I definitely do not agree with the idea that one should cope with illegal XSL-FOs due to multiply defined IDs. But if users choose to do so, they should be given that freedom, I guess.
OK. I added this to the codebase. If strict validation is turned off, FOP will issue a warning to the logger and continue processing. included in http://svn.apache.org/viewvc?rev=434513&view=rev