Re: What's a Referrer?

At 11:42 AM 1/28/97, Terry Allen wrote:
>What's a Referrer?
>
>Section 4.2 reads:
>
>| Many addressing mechanisms assume the existence of some sort of a base
>| address whose value effects the interpretation of the address. To
>| formalize this, every HREF has a location source, an object or objects
>| which serves as the base address. In most cases the location source can
>
>"base address" needs definition.

And it should be defined for each of the closed list of addressing modes
that XML supports. I think we need to decide hwo things are going to work,
so that we are guaranteed that and XML link in an XML linking document can
at least be parsed, and its pointers resolved, by any XML linking
application. If people need to extend XML-LINK they can make an extension
and use a new architecture (and steal whatever they need from ours, if they
want to).

I think it should be crystal clear what is and is not XML-LINK, and that
extensions should be clearly OUTSIDE the spec.

>| be omitted and is implied to be the document element of the document
>| that contains the link. However, this implied location source can also
>| be specified as being the non-link element that refers to the link
>| element (the referrer).
>
>What does that last sentence mean?

I think it's supposed to refer to the previous element in the location
chain (if the processor happens to implement indirect location pointers)

> And if the "implied location source"
>(a.k.a. "base address", which is more homey) is specified, in what
>manner is it still implied?  What is the reason for having both
>locsrc and implied-locsrc?  And it seems as though the "base address"
>may vary with each occurrence of a link element.  Do we need that?

If we need locsrc at all, then it's worth having this. But I think we can
probably do without locsrc.


>This implies that every HREF value has a "base address", whether the
>author intended to employ such a mechanism or not. I wouldn't be
>surprised if that assumption screws up some addressing scheme,
>though I don't have one in mind.  Perhaps this should be qualified
>such that a "base address" is implied only if HRTYPE is an
>addressing scheme that uses a relative addressing mechanism.

This should be cleared up by making explicit exactly what addressing
schemes are supported, and how base addresses or whatever work with each.
We should not have to worry about random new address scheme unless and
until they are integrated into XML-LINK.

>Also, the punt on the format of the string is unsatisfactory.  We
>won't get interoperability unless we can say what the format must be;
>if this varies with HRTYPE then reference should be made to some
>canonical statement of what a "base address string" is for that
>HRTYPE (for HRTYPEs the use of which is anticipated) or it should
>be said that the specification of HRTYPEs that use relative addressing must
>include an unambiguous specification of "base address string" for
>that HRTYPE.  Note that HRTYPEs not mentioned in this spec will not
>be implemented by all implementors.

They should simply not be allowed in documents that claim to conform.
Otherwise we have blown the no-options requirement out of the water by
adding an infinite number of undeclared options for addressing mechanisms.

   I think we need 3 basic types:
   + URLs, as currently used.

   + Structural addressing, i.e. some method of navigating within an XML
document that has a single URL.

   + A way to use SGML entities and IDs for linking (perhaps mostly for
compatibility with the SGML world, perhaps because the options it offers
for management via entities are usful in their own right).

If people need something else, they should use something other than XML
linking to meet their needs.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 29 January 1997 17:28:33 UTC