Re: LYNX-DEV when relative URLs should ignore BASE

[Foteos Macrides]

Al Gilman <address@hidden> wrote:
>to follow up on what Foteos Macrides said:
>
>> The fragments for the text/html "media type" presently have two possible
>> "interpretations".  One is "Go find the MAP for this client-side image
>> map to interpret how clicks in various positions of the image should
>> be handled." (Lynx can't inline images, and has its own, different but
>> homologous interpretation. :)  The other is for positioning within the
>> document.  
>
>The action taken on HREF and on USEMAP is different but the
>interpretation of the fragment in #fragment is one and the same.
>It is a reference into the namespace of anchor.name's and
>other.id's created in the enclosing HTML [etc.] document.
>
>It is one and the same name/reference scheme used both for
>navigation and map linkage.  But for USEMAP, you don't have to
>check that the target is a MAP, its ( NAME | ID ) is known to be
>unique among all identified elements.

        I'm not sure what your point is.  As I quoted, a fragment
"consists of additional reference information to be interpreted by
the user agent after the retrieval action has been successfully
completed" and that interpretation is dependent on the "media type"
which in the the case of text/html means on the HTML specs.  The
HTML 4.0 specs say about the USEMAP attribute:

          This attribute specifies the location of a map defined by MAP
          and AREA. The value of this attribute must match the value of
          the name attribute for MAP.

and for the NAME attribute of MAPs say:

          This attribute assigns a name to the image map defined by this
          element.

So the fragment in this case refers specifically to a MAP element, i.e.,
a section of the document (block, as opposed to point) which begins with
a MAP start tag, ends with a MAP end tag, and has AREA elements in between.
In the case of fragments used for positioning, they refer to points in the
document, without regard to specific elements.  In both cases a NAME
attribute is involved (though in the latter case it could be an ID
attribute), but that is only part of the interpretation, and it would be
a poor implementation indeed which did not ensure that the NAME attribute
associated with a USEMAP fragment belongs to a MAP element.

        As far as your distinction between "action" and "interpretation"
is concerned, what the user agent should do "after the retrieval action
has been successfully completed" is a key implementation factor in making
fragments useful, and that's why they also may be referred to as
"instructions to the client".  Nothing precludes some use, someday, of
fragments with text/html to do things that do not involve NAME or ID
attributes, and they are intended to be useable for any media type,
existing or not yet thought up, including ones to which the concept of
a NAME or ID attribute could not apply.  My point in the previous message
was that you should not get bogged down in thinking about fragments based
on their original use as pointers to positions in resources.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================