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 12:40:11 UTC