[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xml:base and fragments

  • From: Eliot Kimber <ekimber@contrext.com>
  • To: <xml-dev@lists.xml.org>
  • Date: Thu, 04 May 2017 15:22:30 -0500

Re:  xml:base and fragments

Yes, I think my original response was correct, but only because, from the point of the @target attribute, the URI of its document *is* a.html. But obviously that’s not what I thought it meant when I answered originally.

 

But Michael has convinced me and then thinking through the resolution implementation details cemented that it can only usefully be resolved in the context of the document that contains the reference.

 

That is, you can’t use @xml:base to magically make a fragment-only URI refer to something in a completely different document.

 

Cheers,

 

Eliot

 

--

Eliot Kimber

http://contrext.com

 

 

 

From: "John P. McCaskey" <mailbox@johnmccaskey.com>
Reply-To: <mailbox@johnmccaskey.com>
Date: Thursday, May 4, 2017 at 3:09 PM
To: <xml-dev@l...>
Subject: Re: xml:base and fragments

 

This seems the opposite of Eliot’s initial reaction (and mine and I thought Simon’s but maybe not).

Just to be sure then, in my example, a file named example.xml.

    <div xml:base="http://www.dictionary.com/a.html">
      <p>
        <ref target="#apple">Apple</ref>
      </p>
    </div>

The new Kay-informed (and already TEI majority) consensus is that @target points to a node in example.xml, not to one inside the file at a.html.

I’ll go forth and code and encode accordingly . . . .

Thanks all!
John

 

 

 

On 5/4/2017 3:18 PM, Eliot Kimber wrote:

If I’m understanding Michael’s analysis correctly, the implication for address resolution is that, while there may be a resource separate from eg.xml available at the URI http://www.dictionary.com/a.html, that, *because that URI is used as the value of @xml:base*, for the purposes of resolving @target’s value as a URI reference the effective URI of *this document* (meaning the document containing the @target attribute) is http://www.dictionary.com/a.html, and therefore the fragment identifier should be resolved to an element within eg.xml.
 
The normal practice (or at least my normal practice) for resolving such references in an XSLT or XQuery context would be to get the base-uri() of the node containing the reference and then use resolve-uri() to get the absolute URI relative to that base. I would then call document() (or doc()) to resolve the URI reference. 
 
This will fail to return the current document’s fragment with the ID “apple” if document() actually resolved the URI to a different resource (e.g., “a.html”)—the document() function has no way to know that in the current processing context the current document (or at least the subtree rooted at the element specifying @xml:base) should be considered to be the resource at URI “http://www.dictionary.com/a.html”  and not some other resource that is also at the URI when resolved outside the context of the @target attribute’s containing document.
 
Which suggests to me that that logic would be the wrong thing to do—that bare fragment identifiers should always be resolved in the current document, meaning that the value of base-uri() is not relevant.
 
That is, from the point of the of “this document” URI reference, any URI specified with @xml:base *is* the URI of the current document and therefore there’s no need to do further URI resolution *because you already know where you are* and furthermore, any additional URI resolution would be inappropriate because it would likely get you to the wrong resource (meaning, not the current document or no document at all).
 
I just went through the exercise of using XSLT to implement resolution of the ref/@target attribute and realized that you can’t pass a bare fragment ID to document(), at least as implemented by Saxon, as it won’t result in a document. So anyone implementing this in XSLT would necessarily need to distinguish the case of this-document URIs from other URIs that also include fragment IDs and in that code would want to not try to resolve any base-uri() value to a new resource. 
 
Cheers,
 
Eliot
 
--
Eliot Kimber
http://contrext.com
 
 
 
On 5/4/17, 11:21 AM, "C. M. Sperberg-McQueen" <cmsmcq@b...> wrote:
 
    
    > On May 4, 2017, at 7:07 AM, Eliot Kimber <ekimber@c...> wrote:
    > 
    > The base URI of the ref element is “http://www.dictionary.com/a.html” therefore the fragment identifier *MUST* refer to an element within a.html.
    > ...
    >  
    > From: "John P. McCaskey" <mailbox@johnmccaskey.com>
    > Reply-To: <mailbox@johnmccaskey.com>
    > Date: Thursday, May 4, 2017 at 7:53 AM
    > To: "xml-dev@l..." <xml-dev@l...>
    > Subject:  xml:base and fragments
    >  
    > A (somewhat Talmudic) discussion on the TEI mailing list (https://listserv.brown.edu/archives/cgi-bin/wa?A0=tei-l) regarding xml:base has come to a conclusion I want to run by XML-DEV readers.
    > 
    > TEI defines some XML attributes as RFC 3986-compliant URIs that fully honor xml:base.
    > 
    > The question is whether a value in this attribute of the form #fragment refers to an XML element in the document that contains the attribute or to a location specified by xml:base.
    > 
    > The (almost) consensus is that to resolve such a standalone fragment, xml:base values should be ignored.
    
    As one of the exegetes involved in the Talmudic discussion in question, I hasten to note that I have not
    seen anyone suggest that xml:base values be ignored in resolving a relative reference of the form #fragment.
    I don’t know where that characterization comes from, but it’s not a correct paraphrase of any position I have 
    seen taken in the discussion.
    
    > 
    > In this excerpt from example.xml
    > 
    >   <div xml:base="http://www.dictionary.com/a.html">
    >     <p>
    >       <ref target="#apple">Apple</ref>
    >     </p>
    >   </div>
    > does #apple refer to an element in example.xml that has id="apple" or to http://www.dictionary.com/a.html#apple?
    > 
    > The first, right?
    
    The verb “refer to” is not a technical term defined by RFC 3986, and it
    is tightly defined neither in ordinary language nor (as far as I can tell) in
    philosophy of language (that is, individual philosophers of language often
    provide sharp definitions of the term, but not necessarily the same or
    equivalent definitions).  So it’s not clear that the question as asked has
    any definitie answer.
    
    I think the question can be paraphrased using defined terms as “Does
    ‘#apple’ identify the resource 
    
    (1)  …/example.xml#apple
    
    (where … denotes whatever absolute context was present in the URI
    used to retrieve the document in the first place) or the resource 
    
    (2)  http://www.dictionary.com/a.html#apple
    
    ?
    
    The answer, as I read RFC 3986, is “both”.  
    
    If the creator of a document is not happy with that answer, then caution 
    should be taken in the use of xml:base and fragment-only identifiers.
    
    - We know that in the context given ‘#apple’ denotes URI (2), because
    that’s the way xml:base and the rules for absolutizing URIs work.
    
    - We also know that the reference to ‘#apple’ is a same-document 
    reference, as that term is defined in RFC 3986, because the absolute
    URI of the reference is (2), and the base URI is 
    
        http://www.dictionary.com/a.html
    
    and the two are identical, aside from the fragment identifier.  And
    that is how RFC 3986 defines same-document references.
    
    - Of same-document URIs, RFC 3986 observes 
    
       When a same-document reference is dereferenced for a retrieval
       action, the target of that reference is defined to be within the same
       entity (representation, document, or message) as the reference;
       therefore, a dereference should not result in a new retrieval action.
    
    - Since the target of the reference "is defined to be within” example.xml,
    it seems that in context, ‘#apple’ identifies the element in example.xml
    with xml:id=“apple”.  That is, (1).
    
    This all makes some sense if one remembers that the initial purpose
    of the HTML ‘base’ element, whose functionality xml:base is intended
    to replicate, was to provide an in-document representation for the
    document’s URI, for cases where that information is not available
    from the context.  Neither HTML 4.01 or xml:base actually assign
    the meaning “this is a URI for this document” to the construct, so
    it’s not necessarily abusive to use it in other ways.  But the discussion
    of same-document references in 3986 does have the effect of 
    defining the targets of any URIs identical to the base URI (aside 
    from the fragment component) as being inside the current document.
    
    N.B. the discussion here applies even if the reference in question is 
    absolute, not relative — it is not a question of ignoring xml:base when 
    resolving ‘#apple’; the statements in 3986 apply equally to 
    ‘http://www.dictionary.com/a.html#apple’.
    
    
    
    ********************************************
    C. M. Sperberg-McQueen
    Black Mesa Technologies LLC
    cmsmcq@b...
    http://www.blackmesatech.com
    ********************************************
    
    
    
 
 
 
_______________________________________________________________________
 
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
 
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.