ACTION-1970 - Propose list of page access functions

All,

Here is my list of proposed functions related to the page location
(browser) or request information (server).

I think, at the very least, we would like something to help with query
parameters. Something like:

    xf:parameter-names() as xs:string*
    xf:parameter-values($name as xs:string) as xs:string*

We can go further and provide access to more details of the location:

Entire URL:

    xf:location-url() as xs:anyURI

URL parts, following mostly :

    xf:location-protocol() as xs:string
    xf:location-host() as xs:string
    xf:location-port() as xs:string
    xf:location-path() as xs:string
    xf:location-query() as xs:string
    xf:location-hash() as xs:string

(The browser has "pathname" instead of "path", and "search" instead of
"query". Those sound a bit antique and odd.)

Server implementations are not expected to be able to provide
`xf:location-hash()`, as that is known by the client only.

In addition, the following username/password are possible but of
dubious utility:

    xf:location-username() as xs:string
    xf:location-password() as xs:string

On the client, this would be available if you have:

    http://foo:bar@example.org/

At this point it seems (not verified) that only Firefox supports
username/password. On the server, this would translate into obtaining
the username/password of a BASIC authentication, which may or may not
be available.

On naming:

1. We could use a common prefix, e.g. `location-` for all. But
`xf:location-parameter-names()` and `xf:location-parameter-values()`
become very  long in that case.

2. We could also use a different namespace URI for what we would call
a "request" or "location" module.
    - Pros: shorter names, like `l:port()`, and a clearer sense of modularity
    - Cons: a new namespace, and people don't like namespaces.

Feedback welcome!

-Erik

Received on Wednesday, 16 April 2014 05:26:17 UTC