Re: [xml-dev] @xml-base in subtrees included (a) via entity expansion, a

["C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>]

> On Nov 15, 2017, at 2:21 PM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:
> 
> Perhaps resort to a configuration parameter? Such a setting (say "external-fragment-base-uri") with two possible values (say, fragment-root|fragment-parent) representing the "external entity way" versus the "xs:include" way? The default value of such a setting should probably be fragment-root, as the expansion of external entities is part of the XML standard, whereas the expansion of xs:include is not.
> 
> Kind regards, Hans-Jürgen
> 
> 
> 
> 
> Michael Kay <mike@saxonica.com> schrieb am 18:29 Mittwoch, 15.November 2017:
> 
> 
> Patrik Stellman raised a problem on the saxon-help list for which I would appreciate advice.

I am not entirely certain that I understand the problem.  But I infer from your posing the question that:

  (1) Saxon and not your upstream XML processor is taking responsibility for calculating the base URIs elements.
  (2) Your upstream processor, and not Saxon, is responsible for both XInclude processing and general entity expansion.
  (3) Your upstream processor is, as required by the spec, leaving xml:base attributes in the top-level included element items of an inclusion.  And for reasons not at all clear ot me, it is sometimes using a relative reference in the xml:base attribute, and not an absolute reference.

Are those inferences correct?

If any of these fails to hold, I don’t see how any difficulty arises (which means you may need to educate me).


> When an external entity is expanded, and the entity in question contains an element with an xml-base attribute, the value of the @xml:base attribute is supposed to be resolved against the base URI of the external entity itself (not against the base URI of the element into which the entity's expansion is grafted).

Well, yes in some cases.  The value of any relative reference, whether in an @xml:base attribute or elsewhere, is to be resolved with respect to the relevant base URI.
That will be the base URI of the external entity itself if but only if the base URI has not been reset in some way (e.g. by an xml:base attribute on an ancestor).

> But when xi:include is processed, the xi:include processor injects an @xml:base attribute which is intended to be resolved against the base URI of the "include parent" (that is, the parent of the xi:include element).

And whose effective value should be the URI of the included material.  

So in the case where the external material has the structure

  <e>
    <f xml:base=“foo”/>
    <g xml:base=“gar”/>
  </e>

all three elements e, f, and g should have the same base URI when the external material is included via Include as they have when the material is included by way of a general entity reference.  

When an outermost element in the external material itself has an xml:base attribute, the same should (as I read the specs) be true.  Consider the following material, located at http://www.example.net/examples/extenal.xml:

  <h xml:base=“http://example.com/base”>
    <i xml:base=“foo”/>
    <j xml:base=“gar”/>
  </h>

When this is embedded via a general entity reference, the h, i, and j elements will (if I am doing the exercise correctly) have the base URIs 

    http://example.com/base
    http://example.com/foo
    http://example.com/gar

respectively.  When it’s embedded via XInclude, section 4.5.5 of the XInclude spec requires the calculation and insertion of an xml:base attribute whose resolved value will be the base URI of the external material.  That is, xml:base=“http://example.com/base” or a relative reference which will absolutize to http://example.com/base when resolved against the base URI of the include parent.  The base URIs of the three elements should be just as given above.

If the xml:base on the h element is a relative reference, the XInclude processor is responsible for (a) finding the base URI of the top-level included item, (b) optionally calculating a relative reference which, when resolved against the include parent, will absolutize to the value found in step (a), and (c) including an xml:base attribute on the top-level included item containing either the absolute URI found in step (a) or the relative URI found in step (b).


> Saxon, as receiver of events notified by the XML parser, is interpreting the two situations in the same way. If the systemId of an element is different from the systemId of its parent, it assumes that the child element was produced by entity expansion, and that the @xml-base attribute should therefore be resolved relative to the systemId of the child element. But this ignores the possibility that the child element was actually produced by XInclude expansion: this will also cause the child element and parent element to have different SystemIds (as notified by a SAX parser), but this time the @xml-base attribute should be resolved against the base URI of the (new) parent element.
> 
> Can anyone suggest a way in which Saxon, as receiver of SAX events, can distinguish the two cases and interpret them both correctly?

Can you tell your upstream XInclude processor to use absolute URIs in all injected xml:base attributes?

Can you ask it to provide the extension property named “include history”?


********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************