On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 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 > URL-escaped). > * An 'asciiHost' property > asciiSpec/Host is the canonical form, which is what Location currently outputs. gecko's URI class has the UTF-8 spec/host attributes to be more friendly to UI code that might prefer the non-IDN version of the strings. > * A 'param' property (for things following ';') > This one seems unused as best as I can tell. > * A 'directory' property (which may be similar to getting the > pathname and then dropping everything after the last '/'... not > sure). > * fileBaseName and fileExtension (URI might not be the right place > for these, though). > ^^^ extracting those is pretty simple given the currently proposed interface. > * 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). > ^^^ these are convenient -Darin > > -Boris > > >