On Sat, 2020-06-13 at 20:24 +0000, Hans-Juergen Rennau wrote:
> Liam, please help me make sure that I understand you correctly, when
> you say:"What was needed was something like HyTime Architectural
> Forms, to say,
> in this DTD, in this document, such-and-such an attribute, or
> element,
> or combination, represents a link, and _this_is how you construct the
> URL from it."Do you mean *URI construction* from instance data? Do
> you want to point out this difference: whilst XLink presupposes
> ready-to-use URIs contained in attributes, it fails to address the
> construction of URIs from document data, e.g. in the style of URI
> templates (RFC 6570)?
I mean two things.
First, one should have been able to have said, in this vocabulary, that
some element's content is connected to other documents as a link;
second, one should have been able to have constructed an IRI (they were
URLs back then) in the manner of URI templates, yes.
Consider potential explicitly-marked-up links in the following:
<p>When <place>King’s College</place> was founded, the circle had not
yet been invented, which is why <person>John Wood</person> wrote his
seminal <work><title>Rectangles and Quadrangles</title></work>.</p>
One might have,
<link match="place" method="get" uri="lower-case(translate(' ', '-',
.))" />
<link match="work[title]" uri="/search">
<with-param name="title" select="title" />
</link>
(with missing components such as method, server, port etc. having
sensible defaults based on context).
Combining this with mapping elements to HTML equivalents for search
engine purposes, and maybe with automatic/external namespaces that i
proposed at one point, would be a very different approach than XML
Schema :) and would be more focused on meeting needs of people who use
Web browsers and Web search.
Around the time XLink was being developed, though, there were still
SGML people saying the Web wouldn't last, wouldn't scale, would go away
