- From: Dr. Yves Forkl (SRZ) <Y.Forkl@srz.de>
- Date: Thu, 14 Jun 2012 16:07:48 +0200
- To: XProc Dev <xproc-dev@w3.org>
Have you ever tried to delete an attribute which matches a particular value, but couldn't even access the attribute's current value? If this sounds curious to you, here is the full story. In my pipeline I have: <p:for-each> <p:iteration-source select="//xi:include"/> <p:xinclude fixup-xml-base="true"/> <p:viewport match="/*[matches(@xml:base, '/xyz/')]"> <p:delete match="/*/@xml:base"/> </p:viewport> </p:for-each> With Calabash 0.9.44.94, I observe that the value of @xml:base is serialized correctly after the end of this step (and subsequent steps). However, the serialized attribute value is obviously _different_ from the value @xml:base has acquired just after the step <p:xinclude>. For instance, in <p:viewport> the regex '/xyz/' reproducibly matches the value _even though_ the serialized version of @xml:base does _not_ contain '/xyz/'. I suspect this occurs when the Base URI of the xincluded file had to be determined using a path that contained directory '/xyz/' while the latter is not contained in the serialized value of @xml:base. This leaves me with two questions: 1) How can I determine the value @xml:base has just after step <p:xinclude fixup-xml-base="true"/>? (Would I have to implement Base URI Fixup [1] myself in XProc?) 2) How could I amend my pipeline to "force" @xml:base to obtain its "real" value before I am trying to match it? Yves [1]: http://www.w3.org/TR/xinclude/#base P.S.: Don't ask why I have to fiddle with @xml:base at all, it's a little scary... -- Dr. Yves Forkl - Softwareentwicklung SRZ, Bessemerstr. 83-91, 12103 Berlin www.srz.de | Firmengruppe: www.besscom.de tel +49 30 75301-335 | fax +49 30 75301-11335 Satz-Rechen-Zentrum Hartmann+Heenemann GmbH&Co. KG Sitz Berlin | AG Charlottenburg | HRA 8089 Komplementärin Satz-Rechner-Betriebsgesellschaft mbH Sitz Berlin | AG Charlottenburg | HRB 4905 Geschäftsführer: Walter Fock
Received on Thursday, 14 June 2012 14:08:17 UTC