Hypermedia & web architecture

Liam,

I'm changing the thread name as it has gone in a different direction than "why", and I think it may help me when I come back to put some of this stuff on the wiki.

>XML is almost always converted to another format before display by a Web
>browser, though, and Web browsers today are not going to interpret any
>attribute at all on a non-HTML XML element as a link, regardless of how
>you spell it, 

Well, here's my current version of reality. 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 agree browsers are unlikely to look through any _json_ for links, and the need is hardly there since the <script> tag is used to side-step the same-origin policy that is applied to xhr, and browsers know what to expect from a declarative script tag, or at least they think they do.  Having recognizable (ie standard) hypermedia affordance vowels in XML would at least let javascript libraries be built to support them.   

>and few people are likely to serve up non-HTML XML on the
>Web and risk the resulting search-invisibility. 

I think this is a big-picture topic in its own right.  I will make a wiki page for it.

A search client can't RESTfully provide search functionality over media types it does not understand.  For example, google does not provide Dublin Core metadata search (AFAIK), perhaps because  the DC stuff is buried in text/html and is not explicitly called out by a media type, perhaps for other reasons (not everyone uses DC, so why bother).

>For me, a way to say
>"this attribute in a document you can't display or index would be
>treated as a hypertext link, if you could display it and if people could
>fin it" isn't enough of a way forward. 

I'm not saying that... but if that's what's being heard, I have more work to do.

>And explicitly putting MIME
>content types on link elements is definitely a huge, huge step backwards

As an XML web developer and user I want XSLT, or XQuery, (which doesn't have pointy brackets and is therefore lacking ;-)), to be usable  on XML-based media types directly in the browser, in a way that is simple.

This might be accomplished if browsers used the @type to distinguish css from xslt and thereby a) negotiate for the appropriate type and b) delegate processing to the appropriate handler:

<link rel="stylesheet" type="application/xslt+xml" href="mystyles.xslt">

I don't think this pattern is against web architecture, is it?   And if browsers gave a declarative way to load XML resources off the web that they do for json, XML would be a useful family of media types.  

Mime types on links give a hint to applications as to what content types can be negotiated for the resource.   Although deemed 'least authoritative' by that Web Architecture TAG finding I keep referring to, it still seems mighty important and useful to me. 

>they <link elements> would largely be
>ignored by Web crawlers. 

Today`s browsers seem to just assume that what comes from a particular link is going to be of a certain media type.  In other words, they just negotiate mostly for */* and hope for the best.  They probably sniff the content, too, which  _is_ a big step backwards in web architecture.  

>I *do* think it's worth thinking about ways to represent and document
>hypermedia, and declarative link discovery and presentation techniques.

That's great.  There's hope yet!

Peter

Received on Friday, 27 July 2012 23:26:15 UTC