W3C home > Mailing lists > Public > www-tag@w3.org > September 2002

Re: TAG Comments on XHTML 2.0 and HLink

From: Ann Navarro <ann@webgeek.com>
Date: Thu, 26 Sep 2002 12:12:47 -0700
Message-Id: <4.3.1.2.20020926115447.02ef2818@mail.webgeek.com>
To: <www-tag@w3.org>
Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, shane@aptest.com

Elliotte Rusty Harold said, quoting Shane McCarron:

Shane:
 >XLink has never addressed the requirements of XHTML. The XLink 
working >group chose to ignore our last call comments, and chose not to 
support >the requirements that were in their own original goals for 
their >recommendation. The W3C Advisory Committee recognized this two 
years >ago and clearly indicated there should be a more friendly approach 
to >linking semantics that would not require they be explicitly described 
on >every link in every document.

Elliotte:
If you were able to demonstrate a need for these requirements, then this 
point would be relevant. But so far, I am unconvinced that HTML needs 
multiple link attributes on a single start-tag, or that it needs them to be 
named something other than what they are named in XLink.

----------

Ann responds:


The TAG is not debating whether a need for these requirements have or have 
not been demonstrated. Those needs were demonstrated and accepted as needed 
as far back as 1999 when work on XLink was in it's infancy. They were in 
fact requirements placed on the XLink Working Group. Those needs were 
ignored, folded, spindled, and mutilated to allow XLink to follow a desired 
syntax, while debasing those acknowledged and chartered needs as being 
'un-elegant'.

The W3C Advisory Committee further acknowledged these needs as relevant, 
and as work that should be accomplished within the XML Activity when it 
accepted the XLink Rec with the caveat that further work must address the 
issue.

A decree of "XLink should be used for hypertext references in 
user-interface oriented applications"  is inappropriate in the face of 
explicit direction by the governing body of the W3C -- the TAG, to the best 
of my understanding, and participation in reviewing their initial charter, 
does not override AC decisions. This "suggestion" certainly seems to 
attempt to do so.

Regarding backward compatibility and XHTML 2.0.

XHTML 2.0 aims to fix much of what was broken in earlier designs of HTML. 
As everyone should be well aware by now, the XHTML process was designed as 
a "bridge" between HTML and XML. XHTML 1.0 was the starting point, a 
true-to-the-original port as possible of HTML 4.01 into XML compatibility. 
XHTML 1.1 was a restatement of XHTML 1 using the techniques developed in 
the Modularization of XHTML.
XHTML 2.0 is at or near the end of this bridge from HTML to XML.

It should surprise no one that XHTML 2.0 is intended to be designed as a 
generic XML application. We are attempting to avoid any required arcane 
knowledge of our semantics as any other standardized XML vocabulary does 
when it would be important to be able to process these documents using 
standard, generic tools such as Xerces.

XHTML 2.0 retains much of the familiar because that familiar is practical, 
useful, and comfortable. There is no need to reinvent paragraphs, bulleted 
lists, and other simple document structures. XHTML 2.0 does improve upon 
concepts that turned out to be either ill-designed, or incompatible with 
XML methodologies. Frames is certainly one of those technologies, event 
handling is being improved, and the structural semantics of headings have 
been enforced. We believe these efforts to be good things.

However, I must object to the assertion that by making these changes that 
XHTML 2.0 completely disregards the installed knowledge base of  HTML and 
XHTML 1.0. The majority of the elements, their semantics, and their default 
styling (to be provided in a default stylesheet for XHTML 2.0) remain the 
same. We are asking (X)HTML authors to grow within the XML community where 
necessary. We are not asking them to throw their entire understanding out 
the window, far from it. Every move we make away from existing techniques 
and semantics is done with very careful review of both the 'principle of 
least surprise' and the usability of those techniques from a hand-authoring 
perspective.

We accept as a design requirement that tools are not, and are not likely to 
soon be, the overwhelmingly primary means of document authoring. This means 
that such *common and simple* activities as linking to another document, 
linking intra-document, and "linking" images or any other media within a 
document MUST NOT be so complex as to require an authoring tool, or a 
reference work to be continuously propped open on the average web author's 
desk. Links are simple. They must remain so. The current examples given 
quite eloquently by Steven Pemberton are not -- not by any shade of meaning 
of that word.

So far, the review of these examples have primarily centered on whether or 
not the 'embed' semantic has been misunderstood. Quite honestly, if it has 
been so wholly misunderstood by the community that has developed and 
reviewed HLink before it's publication, there is rampant misunderstanding 
within the XML community as a whole (there is plenty of evidence of this 
available). This points to a design flaw in XLink which has been 
acknowledged by members of that Working Group. Efforts to ameliorate this 
situation must be undertaken immediately.

But the issue here is NOT whether 'embed', 'actuate', or 'replace' should 
be used in these examples, it is the complexity and verbosity of these 
examples that should be reviewed closely [1]. Further in terms of usability 
of our vocabulary, these attributes of linking are REQUIRED to be on the 
elements because we cannot assume that the user agent will read the DTD or 
Schema -- just as any other generic XML document cannot assume support for 
DTD or Schema processing.

That the most basic activity of hypertext, linking between documents and 
objects [2], becomes something that the majority of HTML authors will not 
be able to write with their eyes closed let alone without a constant 
reference source, is the ultimate failing of the XLink effort, and a vivid 
demonstration of why the process of ignoring, rejecting, and subversion of 
those requirements, clearly articulated more than 3 years ago, must be 
rectified.

Respectfully,

Ann Navarro
WebGeek, Inc.
Co-Editor of XHTML 2.0
[Speaking as an individual]

[1] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0108.html

The simplest XLink-compatible link example:

<script xmlns:xlink="http://www.w3.org/1999/xlink" 
xlink:href="/scripts/pop" xlink:type="simple" xlink:show="embed" 
xlink:actuate="onLoad" />

[2] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0108.html

Only a slightly more complex linking scenario, now doubled in syntax 
requirements:

<security xlink:href="/security/pref1.xsp" xlink:type="simple" 
xlink:show="embed" xlink:actuate="onLoad" 
xlink:role="http://example.org/security"> <script xlink:href="/scripts/pop" 
xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> </security>
Received on Thursday, 26 September 2002 12:09:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:11 GMT