W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010


From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 20 Sep 2010 01:41:58 -0400
Message-ID: <4C96F426.2070708@mit.edu>
To: Adam Barth <w3c@adambarth.com>
CC: WebApps WG <public-webapps@w3.org>
On 9/20/10 1:02 AM, Adam Barth wrote:
> I've updated the document:
> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#

General comments based on a quick read (and ignoring various typos that 
I figure we'll fix in due course):

1)  The reference chain for actually parsing a URI terminates in HTML5 
referencing the IRI RFC, which doesn't seem to define a parsing 
algorithm.  Did I just miss it?

2)  Why lastPathComponent as opposed to, say, fileName?

3)  Why is lastPathComponent readonly?

4)  Things Gecko has on its URI objects that this seems to be missing
     and that might be useful and aren't obviously available via
     existing facilities of this interface:

   * An equals() method that takes another URI object
   * An 'asciiSpec' property (Host IDN-escaped as needed, other parts
   * An 'asciiHost' property
   * A 'param' property (for things following ';')
   * A 'directory' property (which may be similar to getting the
     pathname and then dropping everything after the last '/'... not
   * fileBaseName and fileExtension (URI might not be the right place
     for these, though).
   * A getCommonBaseSpec() method that will take two URIs and return a
     URI string they could both be relative to, if any.
   * A getRelativeSpec() method that takes two URIs and returns a
     string that represents one as a relative URI relative to the
     other (if this is possible).

Received on Monday, 20 September 2010 05:42:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC