RE: Hypermedia & web architecture

________________________________________
From: David Carlisle [davidc@nag.co.uk]
Sent: July 27, 2012 9:39 PM
To: public-xmlhypermedia@w3.org
Subject: Re: Hypermedia & web architecture

On 28/07/2012 00:25, Rushforth, Peter wrote:
> Javascript is the prevalent standard way to extend the functionality
> of browsers nowadays, and if RESTfully applied, this is called
> code-on-demand.  It allows clients (ie browsers)  which do not
> understand a particular media type to be extended with code that
> does.  So, the understanding of a particular non-HTML media type
> (most often json nowadays) does not need to be pre-programmed into
> browsers

I doubt json is the most common non-html media type handled by browsers.
(css pdf png gif would all be more common I'd guess) 

>Fair enough, though they are sort of ancillary to html, and they might serve to illustrate
>the role of media types, they aren't mostly considered hypermedia formats. YMMV.

>also json parsing
>is (typically these days) directly programmed in to the browser to avoid
>security problems with using a full javascript parser on what is
>supposed to be a subset language. (JSON.parse() rather than eval())

So, parsing is built-in to the browser, as it is for xml.  

>Also as Liam noted javascript is only available if your host document is
>(x)html, it isn't available if you just serve some other xml type.

Why?

>so I don't understand the point you are making here at all.

The point is that the discussion needs to be centred around the interactions between
the client and server, and how the media types, and yes links between them, 
are involved in that interaction.

>Isn't that what <?xml-styleheet spec is for? How does anything discussed
>here help the XSLT case?
>which is exactly the behaviour they do all implement for xml-stylesheet PI.

Why is a processing instruction necessary?  And, can I run an XSLT 2 
stylesheet with that facility?

Peter

Received on Saturday, 28 July 2012 11:27:07 UTC