search

hassanakbar4 / tractive-test

0 stars 0 forks source link

XInclude processing apparently appends ".xml" when needed #381

Closed hassanakbar4 closed 2 years ago

hassanakbar4 commented 5 years ago

component_Version_3_cli_txt resolution_fixed type_defect | by julian.reschke@gmx.de

Apparently, the xi:include processing code supports the same fallbacks as the xml2rfcv2 code for the include PI.

This is a bug because it does not conform to the XInclude processing specification.

(I'll supply an example when needed)

Issue migrated from trac:381 at 2021-10-20 18:30:34 +0500

hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

Xinclude processing is completely handled by the libxml2 library which underlies the lxml python library. If this is a problem, it's probably best to register an issue against libxml2.

For more information, could you provide a pointer to the xinclude specification, showing how this is non-conformant?

hassanakbar4 commented 5 years ago

@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented

You may want to debug this; I'm positive that lxml doesn't have fallback code like that.

FWIW, https://www.w3.org/TR/xinclude/#xml-included-items says:

Resources that are unavailable for any reason (for example the resource doesn't exist, connection difficulties or security restrictions prevent it from being fetched, the URI scheme isn't a fetchable one, the resource is in an unsupported encoding, or the resource is determined through implementation-specific mechanisms not to be XML) result in a resource error.
hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

I'm calling the method xinclude() on an lxml.etree._ElementTree object, nothing more.

hassanakbar4 commented 5 years ago

@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented

...maybe some low-level entity resolver kicks in, which implements some fallback behavior for the "include" PI?

hassanakbar4 commented 5 years ago

@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented

FWIW, "--prep" reports (one example):

        <reference anchor="W3C.REC-SVGTiny12-20081222" target="http://www.w3.org/TR/2008/REC-SVGTiny12-20081222" xml:base="/var/cache/xml2rfc/reference.W3C.REC-SVGTiny12-20081222.xml" quoteTitle="true" derivedA
nchor="W3C.REC-SVGTiny12-20081222">

...which in itself is a problem, as "xml:base" needs to be set to the object that was retrieved.

hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

Right, there's a callback.

hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed status from new to closed

hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed resolution from ` tofixed`

hassanakbar4 commented 5 years ago

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

Fixed in [2756]:

Tweaked the lxml resolver callback to not accept include names lacking extension under v3. Added setting of xml:base before caching xi:include content, in order to not loose the origin. Fixes issue #381.