[uf-discuss] OBJECT include pattern and excess HTTP requests

[Duncan Cragg]

> > PS It's then just a small step to allow off-page includes, which is
> > related to the interlinked hCards on different sites that I was
> > talking about recently on this list.  If anyone can come up with more
> > real-world use-cases for this type of cross-site uF linkage, I'd be
> > most grateful.  Looking further ahead (wrong list for that, I know)
> > I'd see good mashup opportunities from allowing more uF
> > interlinkage...    =0)
>
> interesting ... but the extra complexity that would add to parsers
> (requiring them to do the extra requests) would be a problem.. also what
> about pages being looked at offline?
>

I said this was the wrong list!   =0)

Imagine you replaced 'parser' with 'browser' in the above...

There could be a case for a parallel stream of work in Microformats.
Where, currently, uFs are (very successfully and quite justifiably)
pave-the-cowpath of inside-HTML usage, there may be people who would
like to reuse these standards in other contexts.  That is, outside of
a current web page.

For example, in REST integration (see my 'REST Dialogues' where I go
on about this a lot); or for 'hyperdata' ; bottom-up, small-s semantic
Web (see my 'Micro Web' where I go on about this a lot).

Don't flame. I know I'm out of line here.  :-/  Extending the reach
and scope of uFs while not breaking the process that gave birth to
them is a tricky proposition.

Here at the FT we're thinking about using the uF standards as the
basis of a kind of internal data model (hAtom for our news, hCard for
our companies - nothing ground-breaking), but we need to pull the
standards out from the inside of HTML pages and give them a life of
their own, all linked up.  (I know if I mention JSON for this I'll be
kicked off the list, so I won't do that.  =0)

The www.ft.com pages at the end of this insanity could have those
wandering uFs back where they belong, snugly tucked up in XHTML, with
just a POSH link or two between them, to which current in-page-only
parsers may stay oblivious.

But..  if an hAtom parser could follow links from hfeeds to hentries,
that would be excellent, especially when we may have many hfeeds
pointing to the same hentries - our search results are just lists
without content. Or if an hCard parser could follow links from BT's
hCard to the hCards of their CEO, CTO, etc., I'm sure some of our
readers would approve, especially if the links went back again from a
CEO to their list of board duties. Or what if an hCalendar parser
could go from an hCalendar event for the AGM of BT, via an embedded
list of links labelled 'attendees', to the /same/ hCards of the CEO
and other people known to be attending - even if those hCards are
scattered across the Web.

There's no need to duplicate hCards or hentries.  That's what links are good at.

In fact, let's even try to find cowpaths around /linked data/.  (Not
Linked Data, the big-S version).

The Web's full of links, after all...

Cheers!

Duncan