W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: Who is the Intended Audience of the Markup Spec Proposal?

From: Philip TAYLOR <Philip-and-LeKhanh@Royal-Tunbridge-Wells.Org>
Date: Fri, 30 Jan 2009 09:54:03 +0000
Message-ID: <4982CE3B.1020703@Royal-Tunbridge-Wells.Org>
To: "Michael(tm) Smith" <mike@w3.org>
CC: Ian Hickson <ian@hixie.ch>, public-html <public-html@w3.org>

It is great to see that this discussion has moved
from in-fighting to constructive criticism, and
I would therefore like to raise a technical
point deriving directly from Mike & Ian's most
recent exchange :

>>>> * The spec doesn't define for authors how relative URLs are resolved.
>>> (bug 6505) Is it necessary for it do so? That is, if the purpose of this 
>>> spec remains constrained to describing what a conformant document is and 
>>> what the elements and attributes are meant to represent, would it need 
>>> to describe how relative URLs are resolved?

>> If the purpose of this draft is constrained to describing what a 
>> conformant document is, then it needs enough material in there to make 
>> sure that the reader can check that the document doesn't contain relative 
>> URLs when the base URL can't be used to resolve URLs.
> OK, I see now.

I wonder whether this is a step too far, and whether
we are now considering whether Mike's document should
encompass semantics as well as syntax ?  I ask because
of the following :

> If the base URI given by this attribute is a relative URI, 
> it must be resolved relative to the higher-level base URIs 
> (i.e. the base URI from the encapsulating entity or the URI 
> used to retrieve the entity) to obtain an absolute base URI. 
> All xml:base attributes must be ignored when resolving 
> relative URIs in this href attribute.

This suggests (to me) that whether or not "the base URL can't
be used to resolve URLs" cannot always be determined at
document-creation time, and that the decision may have to be
deferred until the document is elaborated.

Received on Friday, 30 January 2009 09:59:03 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:42 UTC