> > On Feb 15, 2010, at 2:48 PM, Jan Algermissen wrote:
> >
> >> I am not sure a generic approach is feasible because hypermedia can
> take many forms
> >>
> >> - links
> >> - link templates
> >> - forms
> >> - exotic (as in http://www.nordsc.com/blog/?p=293#cbcID-tweak )
>
> Actually forgot such kinds of links:
>
> <app:collection href="http://foo/service/collections/1"> or
> <img src=""/>
I'm no XHTML guru, but I would assume that there is a XSD that defined that
img is an XLink, so a XPath query for XLinks will return it as part of the
link list?
> However - there should really not be a very large number of media types
> (certainly we do not want one per service) and the set of media type
> specific plugins to provide would not be so big that it would not make
> sense to make them (in some way) part of the framework. As a plugin
> package maybe.
If the amount of media typed would be a problem, then it would be impossible
to browse the web. ;-) Certainly it's all about plugins.
> >From this POV it would make sense to discuss general properties of
> >such plugins.
> It would also make sense to provide methods at the level of a user
> agent (not connector) class that allows acess to all the links present
> in the current steady state.
Like "public Map<String role, URI link> receivedEntity.getLinks()" for
example?
> That way I could ask the user agent object if in the current steady
> state there is a 'ship' link. For the caller it would be transparent
> wether the link was in some response header or some representation that
> is part of the current steady state. And things like that should be
> transparent as they are semantically equivalent.
Exactly.
> I could also envision a means to iterate over the items of a steady
> state that 'is' a collection. The actual primary representation of the
> steady state might be RSS or Atom feed or even text/uri-list but from a
> client program POV I just might not care.
Didn't get that point. Can you elaborate?
> So there is some kind of common ground to leverage.
Finally. Sigh. ;-)