OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XHTML 2.0 and the death of XLink and XPointer?

[ Lists Home | Date Index | Thread Index ]


At 10:39 PM 8/11/2002 -0600, Uche Ogbuji wrote:
>Steve Pemberton's e-mail, certainly makes the XLink WG look the guilty 
>party.
>I wonder whether anyone from that WG would deny or explain such arrogant
>behavior.

         I sure would. I think I can speak as to these issues, at least 
until 2000, when I left the group.

         As far back as '98, the HTML WG proposed various requests and 
recommendations for XLink. We spent hours of time on conference calls, and 
at least a few days of face-to-face sessions trying to accomodate their 
requirements. And the fact is that the WG did the best they could. We tried 
out a number of namespace-free solutions to their problem, and couldn't 
find one that would please them...or us.

         A quick look at the XLink issues list, which is now public, will 
demonstrate several issues in which the XLink WG tried to resolve the HTML 
WG's issues. I don't think you'll find any arrogance when faced with the 
evidence of the WG's hard work.

         The fact of the matter, as I see it, is that linking in HTML was 
fairly clumsily integrated over the years. HTML has always been a 
catch-as-catch-can sort of specification, due to browser wars as much as 
anything else. XLink is a reasonably simple, clean spec. People are 
rightfully annoyed that it is ambiguous about things like actuation of links.

         The WG made several decisions in regards to -not- specifying 
behaviour for linking. I disagreed with those decisions then, and I still 
do. This was done, as far as I can tell, to clear the road for the 
multitude of different kinds of linking...and it's left the spec virtually 
ignored, which is unfortunate. I have the same issue with the lack of a 
clear processing model that allows the various XML specs to co-exist 
(especially at a client level).

         We managed to solve some overlap with XPath (where XSLT and 
XPointer met). We never managed to do the same with the HTML WG or the XSL 
and CSS WGs.

         It wasn't for lack of trying, folks. I agree with what I see as 
Uchi's basic point: why are we wasting time pointing fingers, and why 
doesn't somebody from TAG step forward and solve the bloody problem? W3C 
isn't much of a standards organization if they won't step up to the plate 
and say, "This is the standard. Comply with it in your new specifications. 
Yes, we know it will be work, and yes, there may be backwards compatibility 
issues to be solved. Cope."

         That's my perspective of how things went down, for good or for 
worse. We all gave it our best shot, in all the WGs, and to some degree, we 
failed to come to a rapprochement. Such is life.

         Let's fix it. If I come up with anything that seems to click, I'll 
be sure to post it here.

--->Ben





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS