[Home] [By Thread] [By Date] [Recent Entries]


On 9/27/05, Magnus Henriksson (MO/EAB) <magnus.henriksson@e...> wrote:
[...]
If run document.xml through an XInclude processor, I get the following result:

<?xml version="1.0"?>
<document xmlbase="http://example.com"
          xmlns:xi="http://www.w3.org/2001/XInclude" >
  <paragraph>How to handle customers:</paragraph>
  <list xmlns:xlink="http://www.w3.org/1999/xlink"
        xml:base="common/policy.xml">
    <item xml:id="item1">The customer is always right.</item>
    <item>When the customer is wrong, see <link xlink:type="simple"
                                                xlink:href=""#item1"/>.</item>    <graphic xlink:type="simple"
             xlink:actuate="onLoad"
             xlink:show="embed"
             xlink:href=""../images/happy-customer.gif"/>  </list>
</document>


My problem is that the link points to http://example.com/common/policy.xml#item1, but I really want it to point to #item1 in the XIncluded result. The graphic points to http://example.com/images/happy-customer.gif which is what I want.

I think using xpointer here() function and then a relative addressing is not the best way to make
iter-document xlink references survive the inclusion processus. see
   http://www.w3.org/TR/xptr-xpointer/#b2b1b1b3b7b5
the syntactic construct
   xlink:href=""#xpointer(here()/id('item1'))" should work I think at least for implementation not limited to the REC sanctified very limited subset.
The same principle should work for structure based relative links too assuming the relative pointer operates
within the included subset.

Daniel


Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member