> 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
> 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
- Re: Base
- From: Dave Hollander <firstname.lastname@example.org>