Re: Base

While I am interested in the issues surrounding the overloading of base
I am more interested in establishing a "standard" for the linkage concepts
that have not been established as standard practice in the HTML community. 
Lee mentions the SoftQuad use of PI to contain a URL. Great for them, 
but I can not rely on that across vendors. Since concepts like these 
are so useful, can we not work to establish a consistent way to identify 
them to vendors so that they can create richer universal tools?

One particular goal should be that this effort helps improve the ability
to maintain links and a web of links. This goal seems to motivate much of
the syntax discussion. However, simple assumptions about the role or 
meaning of a link greatly improve the ability to maintain a web. Why
should meaning be taboo?



On to the base case:

I am very familiar with RFC 1808 (ftp://ds.internic.net/rfc/rfc1808.txt). 
having had to defend a particular web document that used base in a
non-expected way. I am not always clear in my writing though, so 
I will try again to list the two possible interpretations of 
RFC 1808 in regards to base. Note, while Roy and others deny that the 
spec can be interpreted in multiple ways, many others did see the 
unambiguity. 

1) (traditional) the value of the base is added to all relative URLs

2) the url value for the "resource" (the resource may be reached by 
	multiple routes and may have multiple instances)

The problem arises when a content provider is trying to give a better
URL for use in hotlists than one of the many possible routes to the
document. This may be done for maintenance reasons (a file spec is easier
to maintain than a imagemap coordinate, or, as some on the list noted,
for deception).

> Terry Allen writes:
> | Areas of conflict:
> |  - Should base value *always* be displayed as the address of the document
> | 	in browsers, hotlists, and other processing applications?
> 
> conflict between what?  which document?  do you mean base value or
> base value+relative URL as arrived at per RFC 1808?

Conflict in the discussion list. The spec is ambiguous as to how the
base value should be applied beyond relative URL completion. The
alternative roles for base in an application is not clear.

> 
> |  - Should the base be used to identify an alias for the document?
> | 	If not, how?
> 
> what is an "alias for the document"?  which document?

There can be multiple paths to a resource. The owner should not be held
responsible for maintaining all of them, particularly since many may not
even be under their control. How can the owner identify a prefered
(aka maintained) identifier/url for the resource?

> 
> |  - Should the application of the base value to a partial URL always imply
> | 	a new entity? 
> 
> I think the rather involved algorithm in RFC 1808 does not prohibit
> relative URLs that in fact point to the document containing them, and
> in fact I don't see how it can.  But perhaps I misunderstand
> "imply a new entity."

The RFC does not specify if the object identified by 
BASE + RelativeURL + #loc (my external network connection is down and 
I can find the correct term for "#loc") is indeed the same resource 
as just using #loc in the current resource. This can result in a 
different entity if an explicit base value is not the same as the 
implicit base value (how the resource was reached).


Dave Hollander

Received on Wednesday, 22 January 1997 11:28:52 UTC