RE: TAG Comments on XHTML 2.0 and HLink

Hi Shane,

Shane said:
The HTML Working Group has demonstrated that XLink is manifestly
inadequate for the needs of the community we are trying to serve.  
Our constituents, the millions of people who author and maintain web
pages,
cannot be expected to throw out their knowledge base that is HTML 4 and
XHTML 1.  Nor can they be required to use a bunch of arcane attributes
on every linking element just because there is some approved W3C
Recommendation that is sort of in this space that _could_ be used. 
(Note: I am fully aware that XHTML 2.0 is not fully backward compatible
with XHTML 1.1.  However, the HTML Working Group follows "the principle
of least surprise" with our evolution of HTML, and breaking every link
in
every document as people were trying to migrate them to XHTML 2.0 would
be very surprising indeed.)

Didier replies:
As myself a user of both XHTML profile for wireless and HTML 4.0/XHTML
1.0 (for desktop browsers). I do not understand why you think that the
other modifications brought to XHTML would lead us to be "less
surprised". XHTML 1.0 was off course a "no surprise" spec. Thus, we
already have a "no surprise" spec. XHTML 2.0 cannot be honestly
categorized as a "no surprise" specs and do not provide us the
advantages of backward compatibility. If that would be the case, I would
subscribe to this valid argument (from the social acceptance and reduced
upgrade costs principles)

Shane said:
When we delivered a draft HLink document, we received even more support,
and many excellent suggestions for turning that draft into a generic
solution that will serve our community well.

Didier replies:
Yes and also some complains from others. But I still agree with you that
from the "backward compatibility" principle, it doesn't work. So maybe,
in order to support that principle, closer attention should be paid to
the added modifications. 

Shane said:
The HTML Working Group is in the vanguard of W3C activities.  We often
fall afoul of the problems caused by the ill-considered actions of other
standards groups and governing bodies.  When this happens, we work to
address the problems in conjunction with those groups.  When we cannot
address the problems (e.g., broken XML Namespaces, DTD locations on the
W3C servers, absolute vs. relative URIs in W3C recommendations,
byzantine publication policies, etc.) we find some way around them so
that our user community is served.  

Didier replies:
I can only sympathize with you on that and agree that this is not funny
at all to support it.

Shane said:
At the end of the day, that is all that matters.  The members of the
HTML Working Group attempt to represent our user community.  XLink in
its current form is unusable by that community.  

Didier replies:
If, as a content author you ask me to redo my stuff because some XHTML
constructs are modified or added then, I do not see how xlink bring more
work since I have to redo stuff anyway. At least, I will re-do stuff for
improvement and added value especially if I can re-use the same linkage
processors in different contexts like SVG and MathML, two important
modules I may use in addition to XHTML. SMIL, in the usage context of
XHTML is mostly to add value to the existing constructs... and I would
have to include a SMIL namespace declaration to use it anyway. So...

Cheers
Didier PH Martin

Received on Thursday, 26 September 2002 12:30:34 UTC