[
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.
I really appreciate it, and I'm sure others do.
> 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.
But was the use of namespaces really their biggest problem? Why? Because the
documents would have to add another namespace (silly objection, that)?
Because they wanted all elements of their vocabulary in one seamless
anmespace? (I can't think of any technical reason for needing this).
When the HTML folks talk about distaste for adding a new namespace, it baffles
me. I just looked: XHTML 2.0 uses namespaces. They should either have
ditched namespaces altogether, or accepted namespaces for their value. Since
they use namespaces, and thus would not, I think, expect another vocabulary to
use their use of namespaces to refuse to embed HTML, then they too should not
use XLink's use of namespaces as reason to shun it, without particular
technical justification (which I am yet too see). i.e. unless the HTML groups
is saying they think it's OK for others to shun XHTML 2.0 for it's use of
namespaces, they are being hypocritical.
> 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.
Just to be clear to all, I was not accusing the XLink WG of arrogance at all.
I was saying that the behavior Steve Pemberton described was arrogance. I'm
not surprised there are more sides to the story than he puts forth.
Anyway, where is the XLink issues list? I can only find the pointers to the
comments group and archives in the REC itself (forgive me: I don't have the
time to comb through all of these). Googling for "XLink issues list" and even
"XLink issues" bears no quick fruit.
> 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.
This is one of the things that do annoy me about XLink. I wish it had not
attempted to add constructs that even hint at processor behavior. I think
Paul Prescod and others fought against this much earlier on.
> 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).
I don't have a problem with there being a suggested processing model. I just
don't think this belongs in the XLink spec. There could be an XLink
processing spec, which adds actuate="" (and the additional constructs that are
needed for complete specification of processing), and users of XLink could use
its suggested processing model where it makes sense, but not as core XLink.
> 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.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
Basic XML and RDF techniques for knowledge management, Part 7 -
http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra
ry/x-jclark.html
Python and XML development using 4Suite, Part 3: 4RDF -
http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A
1EA5A2CF4621C386256BBB006F4CEC
|
