[
Lists Home |
Date Index |
Thread Index
]
Uche wrote:
> So now he has explained clearly (for the first time, I think) why
> the HTML WG came up with HLink. XLink did not fit well with their
> test cases, so they specialized their own solution. The problem is
> that HLink is really no better than XLink. It solves just as limited
> a set of concerns. I think we've all gained nothig if we just add
> another linking technology that covers a similar profile of problems
> as XLink, but with a somewhat different specialization.
>
> I got the earlier impression that HLink was generic, and thus
> somewhat akin to architectural forms. As I've said, I've been
> warming to this approach since the XHTML/XLink quarrel broke open.
>
> So imagine my surprise to read HLink and find that it is no more
> generic than XLink, and really nothing more than a set of selectors
> for presentation semantics related to linking. Why didn't you guys
> just define a new group of CSS selectors? That would have been far
> more sensible than the compulsive wheel reinvention that I see in
> HLink.
I agree with Uche that HLink doesn't seem to be situated at the right
level in the architecture. I don't *quite* agree that CSS would be the
right way to do it -- I think it would be reasonable for CSS to tackle
the behavioural aspects of linking, but don't think it's right for
tackling the semantic "I am a link to a picture" aspect. (I've never
been particularly comfortable with the way that XLink conflates the
two.)
It seems to me that XHTML wants to be able to say things like "all img
elements point to an image (to be embedded when the document is
loaded)". This linking semantic is something at the *markup-language*
level, not at the level of an individual *instance document*.
[Or is it anticipated that individual authors might change this
semantic for their documents? If so, I think it's much more likely
that authors would want to have control at the level of individual
images rather than at the level of the whole document.]
I can think of two ways in which you might specify the semantics of
elements and attributes in a markup language in this situation:
1. If there is another standard, recognised markup language that has
the semantics that you want to use, you can describe the semantics
of your markup language in terms of a transformation from your
markup language into that standard markup language. That way,
applications that understand the standard markup language can work
on the transformed version of the document, but you can retain the
domain-specific terminology that you prefer.
2. If there isn't a standard markup language to map to, or for
whatever reason you don't want to use that method, the proper
place to describe the semantics of a markup language is within a
schema. If you can come up with a generic way of describing the
semantic that you want to assign to the elements and attributes,
then you can embed that description within a schema. That way,
applications can study the schema for the markup language in order
to work out what to do with the elements that they have to handle.
I guess these are really the same -- it comes down to having a
centralised representation of the semantics (linking semantics in this
case) within a schema. To my mind, these kinds of cases are precisely
why xs:appinfo in W3C XML Schema, the ability to add annotations in
RELAX NG, and the ability of Schematron to provide outputs that aren't
necessarily validation reports are so useful.
I view AFs as doing #1 -- mapping from one markup language to another.
As far as I can tell, the XHTML/XLink tension is interesting because
XHTML needs more than an attribute-value-to-attribute-value mapping
since each XHTML element can have several attributes describing
different links -- something that XLink doesn't allow. But what if you
had XSLT templates (or some other transformation technology)
describing the mapping:
<xsl:template match="xhtml:img">
<xhtml:img xlink:type="extended">
<image xlink:type="resource" xlink:label="image">
<xsl:value-of select="@alt" />
</image>
<src xlink:href="{@src}" xlink:type="locator"
xlink:label="src" />
<go xlink:type="arc" xlink:from="image" xlink:to="src"
xlink:show="embed" xlink:actuate="onLoad" />
<longdesc xlink:href="{@longdesc}" xlink:type="locator"
xlink:label="longdesc" />
<go xlink:type="arc" xlink:from="image" xlink:to="longdesc"
xlink:show="new" xlink:actuate="other" />
</xhtml:img>
</xsl:template>
To illustrate the second option, perhaps we can agree on a set of
schema adjuncts that we can use to say "this element defines links to
other resources as follows...". Perhaps it could even look similar to
HLink:
<element name="xhtml:img">
<attribute name="src">
<hlink:hlink effect="embed" actuate="onLoad" />
<data type="xs:anyURI" />
</attribute>
<optional>
<attribute name="longdesc">
<hlink:hlink effect="new" actuate="onRequest" />
<data type="xs:anyURI" />
</attribute>
</optional>
...
</element>
though since the effect here it mainly to describe behaviour, my
personal preference would be to use something along the lines of XML
Events to describe the actions and reactions to clicks and secondary
clicks and load events and so on.
I guess that you could view a separate HLink document as being like a
specialised schema, and the hlink:definition attribute as being like a
link to that schema. (Hmm... presumably the hlink:definition attribute
needs its own hlink:hlink element to describe it?) But we already have
(rather too many) mechanisms for linking from an instance document to
a process that can assist an application in understanding what to do
with that document. Plus linking semantics are not (I'd argue) things
that change from instance document to instance document, so it seems
tedious to have to assert a link to exactly the same specification
document in every instance document.
While I'm writing, I might as well say that since XHTML is (like XSLT,
XSL-FO, SVG etc.) mainly a prospective, application-bound language [1]
-- one that is largely defined in terms of how it's treated by
applications -- I'm not convinced that it really needs to define the
semantics of its elements in a generic manner. Labelling XML elements
as links is really useful if you're likely to be using a generic XML
application to process that markup language, but I think that in
XHTML's case, it's likely that most applications will recognise and
know how to handle XHTML without reference to an external schema. Of
course I might have overlooked some use cases here...
Cheers,
Jeni
[1] http://www.piez.org/wendell/papers/beyonddistinction.pdf
---
Jeni Tennison
http://www.jenitennison.com/
|
