Re: TAG Comments on XHTML 2.0 and HLink

At 12:12 PM -0700 9/26/02, Ann Navarro wrote:


>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'.

I do remember these requirements on XLink. I do not remember any use 
cases justified them, but it was several years ago. If they have been 
previously published, please provide references so I may check them 
out, and perhaps understand your objections to XLink.

>Regarding backward compatibility and XHTML 2.0.

>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.

A generic processor can read the DTD. That is much easier than 
understanding HLink, which brings a whole new level to the equation.

>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.

The TAG apparently feels that links are  ill-designed and most 
especially incompatible with XML methodologies. I'm not sure that I 
agree with them, but even if they're wrong, the argument is between 
old-style HTML linking and XLink. HLink doesn't help. If you think 
linking is not ill-designed and incompatible, then stay with the old 
syntax.

>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.

I think you've moved far enough away to almost completely eliminate 
the ability of existing HTML tools to process or generate XHTML 2.0. 
Furthermore, while you  have good reasons for breaking backwards 
compatibility, you have so many good reasons that you're really 
looking at anew language. Don't kid yourself that this is going to be 
friendly and familiar to web designers. The change from old-style 
links to XLinks need be no worse than the other changes  the WG has 
endorsed. The incremental addition in unfamiliarity caused by moving 
to XLink is  tiny.

>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.

Yes, but those examples are severely flawed. Xlink can and should be 
much simpler than this.

>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.

Yes. W3C specs are often misunderstood. Until this popped out of the 
woodwork I thought xlink:show was fairly straight-forward, but I 
guess I was wrong. I'll try and do a better job of elaborating on 
what it is and is not in the next editions of my books.

>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.

Every existing browser with any significant market share is based on 
foreknowledge of the meaning of particular tags and attributes 
including href. There's no reason this will be any different for 
XHTML 2.0. Browsers will know that particular elements should be 
treated as simple XLinks, even if they don't read the DTD to see the 
xlink:type="simple" attribute.

>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.
>

*All* an XLink based syntax need require authors to type is 
xlink:href attributes instead of href/src/longdesc attributes. Your 
accusations of verbosity are not plausible. The XLink syntaxes you 
have suggested are far from simplest that would work.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Received on Thursday, 26 September 2002 12:49:10 UTC