URL spec parameter-related methods use "parameter" in a way inconsistent with the URI RFC

The current draft URL spec has a number of Parameter-related methods (getParameterNames, getParameterValues, hasParameter, getParameter, setParameter, addParameter, removeParameter, clearParameters)[1]. Apparently these methods refer to key-value pairs in the query part of the URL as "parameters". However, the term "parameter" is used by the URI RFC[2] to refer to something else, a semicolon-delimited part of a path (which I think is nearly obsolete in modern use; I am not sure what it is for). I understand that for legacy reasons, much of the URL interface cannot be consistent with RFC-official terminology. But it seems like a bad idea to use the same term for a different piece of the URL, worse than using the same term for a different part. At least call it something like "query parameters" to disambiguate.

Another point of feedback on the parameter-related methods: they seem to form a dictionary-style interface, and it seems inelegant to have all these different methods giving a dictionary-style interface to something that is a piece of the URL, rather than something that is the URL.

One possible way to solve both these problems:

interface URL {
    StringMultiMap queryParameters;
}

interface StringMultiMap {
     sequence<DOMString> keys;
     sequence<DOMString> getAll(DOMString name)
     boolean contains(DOMString name)
     DOMString? get(DOMString name);
     void set(DOMString name, DOMString value);
     void add(DOMString name, DOMString value);
     void remove(DOMString name);
     void clear();
}

The StringMultiMap interface could be reusable for other, similar key-value list contexts.

Or else use an appropriate dictionary type from ES if one is ever provided.

Regards,
Maciej


[1] http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#dom-url-getparameternames
[2] http://www.ietf.org/rfc/rfc2396.txt

Received on Thursday, 24 May 2012 09:30:29 UTC