Re: ACTION-353: Client-side identification in Ajax applications

> 
> So, with this background, we can consider the example of an Ajax
> mapping application, and explain with some rigor why it is that the
> client-side AJAX can generate and present to the user (e.g. for
> copy/paste or emailing) a variety of URIs that both the server and
> the client will understand as identifying maps centered on a
> particular location, with a certain zoom level, etc.:
> 

OK, except I don't see different x-y-z coordinates as different
resources (I see them as different views of the same map), so I'd like
to offer some counterpoint, taking fragment URIs into consideration.

>
> 1) We assume that the resource authority controls the server at 
> http://maps.example.com and is also the provider of the mapping 
> application served from such that server.
>

I'm going to assume "server 1" is my latitude-longitude application,
and that it acts on a world-map resource served as image/svg+xml by
"server 2".

>
> 2) The authority decides to assign the class of URIs:   
> http://maps.example.com?latitude=xxx+longitude=yyyy+zoom=zzzz.
>

Server 2 controls a resource, /world-map.svg, which is a Mercator
projection of Earth.  By virtue of assigning the image/svg+xml media
type, the authority advertises a fragment syntax for x-y-z coordinates
(plus rotation, etc.).

>
> When
> an HTTP GET is received for any of these URIs, the server responds
> with a representation of the map centered at {latitude,longitude} and
> zoomed to the requested level.
>

In my example, the common understanding of a standard media type allows
any SVG client to understand URI-fragment coordinate syntax.  It is the
client that centers and zooms the single map resource.  An analog to
the problem, is rotating a globe -- same globe, different view.

>
> In the most interesting case, the
> server does this by sending to the client Javascript+HTML Ajax logic
> that will, initially, present the requested map.
> 

Server 1 in my example, provides client-side Javascript logic which
converts a latitude-longitude URI fragment into a native SVG fragment.
The user can copy-paste latitude/longitude URLs from Server 1, as per
the code Server 1 sent the client, or guess their own latitude/
longitude.

>
> Now consider that the user pans the map to a different location, or
> zooms it.  The user then requests from the Ajax application a URI
> that can be emailed, and that represents the new map location and
> zoom.
> 

Right.  I'm considering an alternate case where the server is oblivious
to matters of a coordinate system, as with any other view of a
representation, i.e. an HTML fragment pointing to a named anchor
provides a view of that document, not a separate resource where that
view is scrolled to the top.  I don't see centering or zooming a map to
be any different a use-case than fragment IDs in HTML (nor does SVG).

>
> 3) Just as the HTML form mentioned in [1] encodes the assignment 
> authority's knowledge of the URI assignment policy, the Javascript at
> the client encodes map.example.com's policy for assigning URIs to map 
> locations.
>

With you so far...

>
> So, the URIs generated at the client are indeed traceable
> to the assignment authority, and just as in the HTML form case, we
> can explain why the same party is responsible for their consistent
> use at the client and the server.
>

...now you lost me.  In my example, the URIs generated by the client
are traceable only to the client's common understanding of a standard
media type.  If anyone is accountable here, it's w3c.  Comparing this
to the HTML form case oversimplifies matters.

>
> Indeed, the server and the client
> share knowledge of this assignment policy;  either will present the
> correct map for this URI (the server would do this for an HTTP GET;
> the client might do it locally when the BACK button is pressed, if
> sufficient information has been cached.)
>

The back button works perfectly well in my example, particularly as
there is only one resource to cache.

>
> 4) As with the HTML form case, such client-side manipulation is more 
> suspect in the case where the Javascript manipulates URIs that are
> from a different site (authority).  This is exactly parallel to the
> case of an HTML form from site (authority) A generating and
> submitting URIs from site B.  These may well be correct too, but it
> is A's responsibility to have correct knowledge of B's assignment
> policy, and to properly reflect it in the HTML Form or AJAX
> Javascript.
> 

Server 1's clients have the additional ability, provided through
scripting, of translating latitude/longitude fragments.  These URIs are
traceable to Server 1, and indeed the same party is responsible for
their consistent use, not Server 2, which has no latitude/longitude
interface.  Clients only understand these URIs by virtue of the
Javascript sent to them by Server 1.

If Server 2 changes to the Mollweide projection, Server 1 must change
its algorithm, but this shouldn't have anything to do with URIs or Web
architecture.  Bookmarks based on SVG x-y-z would still work, but would
point to different latitude/longitude coordinates, whereas latitude/
longitude URIs would break (by returning the wrong coordinates, even if
those coordinates identify some location) until the algoritm is updated.

So Server 1's responsibilities go beyond having correct knowledge of
Server 2's assignment policy, to ensure its URIs function properly --
starting with media type, and extending into Server 2's specifics, i.e.
Mercator vs. Mollweide projection, embedded within hypertext.  IOW,
it's Server 1's responsibility to understand Server 2's API, including
URI assignment policy.

>
> I think this is a good story that shows how an important aspect of 
> traditional Web architecture extends directly to Ajax Web
> applications. I suggest we consider including an analysis like this
> in the next WD of the finding "Usage Patterns For Client-Side URL
> parameters " [2].
> 

I'd obviously rather see that document discuss the SVG URI pattern,
in preference to or alongside of, any example using matrix URIs to
accomplish the same objective (say, map viewing).

>
> I think it's worth further distinguishing two cases:
> 
> Case A. The generated URIs are being used purely at the client, e.g.
> for putting on the history stack so the BACK/FWD buttons will work.
> This case is of less interest, because in this case the URIs don't in
> general leak out from the client.  The client could probably get away
> with using a local policy that the assignment authority knew nothing
> about (as long as the client did not inadvertently push on the
> history stack a URI that was used by the server for a different
> purpose.)
> 
> Case B. As in the mapping example above, the client-generated URIs
> are to bookmarked, emailed, etc., and thus may later be presented to
> the server for dereferencing.
> 
> I think B is ultimately the more interesting case, and we should be
> sure to tell that story.
> 

My example solves for both A and B, or rather, doesn't run into either
problem.  The takeaway here, is that any URI syntax that's a product of
the authoritative media type MUST take precedence, and it's incumbent
on Javascript authors to avoid collisions.  You're sidestepping the
issue of fragment precedence (media type vs. scripting, where the issue
at hand provides an opportunity to settle it), by presenting a matrix-
URI example to the exclusion of w3c's own fragment-URI solution to the
coordinate-mapping problem.  IMHO.

-Eric

Received on Monday, 8 March 2010 05:42:42 UTC