search

emezac / tubular

Automatically exported from code.google.com/p/tubular
0 stars 0 forks source link

step implementation: p:xinclude #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
http://www.w3.org/TR/xproc/#c.xinclude

Original issue reported on code.google.com by herve.qu...@gmail.com on 7 Feb 2011 at 7:49

GoogleCodeExporter commented 9 years ago

Original comment by herve.qu...@gmail.com on 7 Feb 2011 at 7:49

GoogleCodeExporter commented 9 years ago 
err-c0029-001 : pass
err-c0029-002 : pass
xinclude-001  : pass

xinclude-002  : fail => need p:log implementation
xinclude-003 to 005  : fail => uri resolver problem ?

Original comment by emmanuel...@gmail.com on 10 Mar 2011 at 5:03

GoogleCodeExporter commented 9 years ago 
I'll try and implement p:log tonight then.

Original comment by herve.qu...@gmail.com on 10 Mar 2011 at 7:44

GoogleCodeExporter commented 9 years ago 
http://code.google.com/p/tubular/issues/detail?id=27

Original comment by herve.qu...@gmail.com on 10 Mar 2011 at 7:46

GoogleCodeExporter commented 9 years ago 
Basic p:log support is implemented. There are improvements to apply (documented 
in the related issue) but it should be enough for the current issue to go on.

Original comment by herve.qu...@gmail.com on 10 Mar 2011 at 10:15

GoogleCodeExporter commented 9 years ago 
usage of xincproc (xinclude processor specific projet: 
http://code.google.com/p/xincproc/)

xinclude-003 to 005 (required) : pass
xinclude-002 : fail => it seems to be a problem with baseuri of document's node 
(absolute uri returned while test stands for relative one)

Original comment by emmanuel...@gmail.com on 4 May 2011 at 6:54

GoogleCodeExporter commented 9 years ago 
Indeed there might be some problem with the base URI of nodes. I have been 
working of completing the p:viewport step compliance lately but I'll give this 
xml:base issue a try as soon as I am done with p:viewport.

Original comment by herve.qu...@gmail.com on 4 May 2011 at 7:09

GoogleCodeExporter commented 9 years ago 
err-c0029-002 : fixed
xinclude-001 to xinclude-006 (optional) : pass

Original comment by emmanuel...@gmail.com on 15 May 2011 at 2:33

GoogleCodeExporter commented 9 years ago 
Regarding xinclude-002: Just to be sure I understand the issue, here is the 
output from the step (/tmp/out.xml):

<?xml version="1.0" encoding="UTF-8"?>
<document>
  <para>some para</para>
  <para xml:base="xinclude/para.xml">another para</para>
</document>

Hence the attribute value is relative. Is base URI fixup supposed to fix paths 
from the top-level document in case of a recursive include? Is so, that would 
give us "doc/xinclude/para.xml" which would have the p:when test evaluate to 
true:

<p:when test="/document/para[2][contains(@xml:base, 'doc/xinclude/para.xml')]">

I am not really aware of all the XInclude specification details though. Am I 
missing something here?

Original comment by herve.qu...@gmail.com on 23 May 2011 at 6:55

GoogleCodeExporter commented 9 years ago 
With reflexion, I think you right and there's no error with baseuri on this 
test.

The value of base attribute must be base URI of the element, or an equivalent 
URI reference relative to the base URI of the include parent (cf. 
http://www.w3.org/TR/xinclude/#base).

I presume Calabash don't compute relative URI and use the base URI of the 
element so the xml:base contains string "doc" (and so on the complete path to 
para.xml document).
A simple test done with calabash confirm my opinion:
<document>
  <para>some para</para>
  <para xml:base="file:/D:/calabash-0.9.23/doc/xinclude/para.xml">another para</para>
</document>

On my mind xml:base="xinclude/para.xml" is correct too because resolving this 
URI to base URI of the document [this.baseURI.resolve("xinclude/para.xml")] 
produce the right URI.

Original comment by emmanuel...@gmail.com on 25 May 2011 at 10:19