Announcing HLink: rationale

XML has what you may call 'host languages', and what you may call
'integration languages'. A host language has a root element, and may host
other languages. For instance XHTML can host Math or SVG or many others by
allowing those languages to be integrated into its structure. Integration
languages on the other hand are designed to be hosted by other languages;
they typically don't have a root element (though they may): Xlink for
instance, XForms, XML Events. These usually have elements and attributes
intended to be used by other languages. Some languages can be both host and
integration (SVG for instance, and XHTML is also used this way by some).

1) Suppose we have an integration language 'XML Handlers', that has an


and as an option the <script> element may have an attribute pointing to an
external resource:

    <script src="/scripts/pop" />

and someone complains that this should use XLink, so it gets changed to:

    <script xmlns:xlink=""
        xlink:href="/scripts/pop" xlink:type="simple" xlink:show="embed"
        xlink:actuate="onLoad" />

2) Suppose we have another integration language "XML Security" that requires
adding references to security preference files via a URL

    <myElement xsecurity:preferences="/security/pref1.xsp">

Someone says they should make this XLink compatible, so they instead
just define a new xlink:role "":

    <myElement xlink:href="/security/pref1.xsp" xlink:type="simple"
        xlink:actuate="onLoad" xlink:role="" />

Well, now when we want to integrate XML Handlers with XML Security, we can't
put a security preferences URI on the <script> element because it already
has a URI. So we can't integrate the two: we have to redesign one of them;
integration is impossible.

We can't redesign XML Security because it doesn't have any elements, so we
have to redesign XML Handlers.

Well, we can't make the security preferences a child of <script>

<script ...>
    <security ...>

because that would clash with the intended semantics of 'embed' on the URI
on the <script> element. So how about making it a parent of <script>:

    <security xlink:href="/security/pref1.xsp" xlink:type="simple"
        xlink:actuate="onLoad" xlink:role="">
        <script xlink:href="/scripts/pop" xlink:type="simple"
            xlink:actuate="onLoad" />

Oh no. That contradicts the embed property too. Oh well, then we have to
create a brand new extended link element:

    <secureScript  xmlns:xlink=""
        <resource xlink:href="/security/pref1.xsp"
                   xlink:type="locator" xlink:label="security"
        <resource xlink:href="/scripts/pop"
                   xlink:type="locator" xlink:label="script"
                   xlink:role="whatever" />
        <resource xlink:type="resource" xlink:label="here"/>
        <arc xlink:type="arc" xlink:from="here" xlink:to="script"
                xlink:show="embed" xlink:actuate="onLoad" />
        <arc xlink:type="arc" xlink:from="here" xlink:to="security"
                xlink:show="embed" xlink:actuate="onLoad" />

though I'm not sure where I'm going to put my inline script in this anymore
(and I left a few things off, to simplify it and save my wrists).

3) And then along comes the XML Privacy group that introduces the XML
Privacy specification that says that in order to reference a privacy
preference file from XML, you have to put a URL ... no let's not do that

All we wanted to say was

    <script src="/scripts/pop"

HLink, just released, allows you to define this.

Steven Pemberton
Chair W3C HTML Working Group, co-chair W3C Forms Working Group.

Received on Friday, 13 September 2002 12:52:47 UTC