[
Lists Home |
Date Index |
Thread Index
]
> Uche Ogbuji writes:
> > Thanks for the history. It's a fun read. I was hoping that it would
> > shed some light on the technical problems the XHTML folks encountered
> > in trying to use XLink. IOW, they don't really help explain current
> > arguments to me. And why in particular do you think namespaces are a
> > problem in XLink? The only point I've heard from the XHTML folks so
> > far wrt XMLNS are that the XLink namespace is extra to type. Surely
> > this isn't what you mean?
>
> I think the notion is that XLink was originally a toolkit for describing
> linking semantics, which used an architectural forms [based|like]
> transformation to connect those semantics to other vocabularies. There
> was a vocabulary, but you didn't have to use that vocabulary explicitly
> thanks to the remapping.
>
> In later drafts, post-namespaces, XLink became just a vocabulary. To
> use XLink, you must use attributes in the XLink namespace. While in
> some ways this just a shift from the abstract to the concrete, it's a
> pretty large imposition on vocabularies that already have linking
> semantics (like HTML - not just A but images, forms, objects, etc.).
Why is using attributes with namespaces a bigger imposition than a requirement
for implicit transform in order to avoid attribute clashing? I guess it comes
down to your recent post about not being sure about declarative versus
procedure. The namespaces approach is as purely declarative as it gets. The
olden-days-XLink approach is declarative, but with a strong hint of procedure.
I personally almost always prefer declarative to procedural, and this is no
exception.
Nevertheless, I can understand your preferring the older approach. I think a
lot of that comes down to general preference. What I don't understand is
where the matter is that is grave enough for the XHTML WG to entirely ditch
XLink.
> For yet a different approach to squaring this circle, see:
> http://www.w3.org/TR/xlink-naming/
>
> I'm not sure I particularly love any of these mechanisms, but I can
> certainly see why the XHTML folks are angry.
Ann hinted that attempts were made to discuss/resolve issues with the XLink
issue, and that these were rebuffed. If this is the case, then I could
understand the WG members' being angry. This would just tend to indicate that
the W3C is tending towards uselessness. But I can't understand "anger" at
these supposed technical issues. The XSLT and XPath WGs faced down all the
namespace issues, real and imagined, and still managed to emerge with
brilliant specs which have stood the test of time. Without thinking too hard
about it, I'd say the only significant wheel re-invention they did was
xsl:include, which I encourage people not to use (if you really need it, use
entities). I am personally disappointed (not angry) that the XHTML WG seems
to have found the oddest sorts of excuses not to rise to the occasion in the
same way.
Listen, folks. XML *needs* a general and credible linking specification.
XLink is not perfect, but with the emergence of things such as XHTML 2.0,
there is an opportunity to improve it in the light of practical needs of
another WG. The two technical matters Micah brought up that make sense to me:
the restrictions on the values of actuate and other such attributes, and the
weasly wording about the content of complex linking elements, should be
matters for relatively non-controversial fixes. If the XLink and XHTML WGs
were not able to sort this out in conference, shame on them. This is exactly
the reason that W3C omerta infuriates me: whatever blackguard was standing in
the path of resolution is safe from the deserved criticism of his or her peers.
BTW, XML Topic Maps was able to use XLink quite well. It seems their demands would be more exacting than those of a hypertext presentation format. I have long expressed support/desire for an RDF serialization that uses XLink, and in the little experimentation I've undertaken, I also don't see the insurmountable problems XLink poses.
--
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/library/x-jclark.html
Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC
|
