Re: HLink

On 8 July 2013 19:25, Liam R E Quin <liam@w3.org> wrote:

> On Mon, 2013-07-08 at 09:01 +0100, Stephen D Green wrote:
> > I agree that XPath adds too much unnecessary
> > complexity. If part of the idea is to support bots
> > and crawlers it might be too much for them.
>
> Which programming language suitable for writing bots does not have XPath
> in it already?
>

OK. I guess. But what importance is there in a link pointing to an element
or attribute within some XML rather than just being a URL to a resource?

I guess too I'm a little worried that XPath is too XML-specific (too much
of
a DSL, if you can call XML a 'domain'). Keeping the technology to URLs
seems far more realistic for the link aspect of the use of hypermedia.

I'm not sure we'd call the URL (or URI) format a language but if we did it
would seem to be the most appropriate one for hypermedia links and
adding a requirement to support XPath seems like a bit more complexity
than is warranted by the benefits, to me. Unless I'm underestimating the
benefits and/or overestimating the costs.



>
> > Supporting 'header' level links is clearly a must.
> > Not so sure whether support for links within the
> > actual XML ('body') is so important though, is it?
>
> You don't get much hypertext with them. Also, XML doesn't have the
> concept of a head and body :) unless you mean HTTP headers.
>
>
>

I'm thinking that hypermedia tends to functionally split into two: Document
level links (which might be called header level links) and links embedded
in the body/markup/content. I guess with XML or JSON the header level links
could be in a separate header resource or could be in the HTTP header
or both. Logically there seems to be these two distinct types though,
wherever they are located. The technology to add document/header
level links seems simple enough. The technology needed to distinguish
parts of the content/markup as links seems to be a sticking point, needing
awkward technology like HPath or AF which seems to require markup
or equivalent syntax of its own. I think that's to be avoided for similar
reasons
to my thinking XPath is to be avoided. It adds more 'languages' to the mix.
That costly complexity, to my mind, warrants close analysis of the benefits:
What value is there in distinguishing links within the content/markup?



So I think we have two areas here: the source of the link and the
resource to which the link points. On the matter of the source we can
identify those in some kind of header which link the whole resource
to other resources and, secondly, those within the document which
link from specific elements or attributes. On the matter of the destinations
of the links we can see those to which a URL would point and those to
which we might need to use XPath to point.

1. Link source
 a. linking from a document (in some kind of header)
 b. linking from a specific node within a document (added complexity here)

2. Link destination
 a. linking to a resource via, typically, a URL
 b. linking to a node or set of nodes within a resource (for which we might
       want to use something like XPath but with added complexity)


Cheers

Stephen D Green



>
> Liam
>
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
>
>