[
Lists Home |
Date Index |
Thread Index
]
> Hi Tim,
>
> >> * There's no concept of a link that is part of a form
> >Well true, but there's no notion of a link that is part of a fish or a
> bicycle either.
>
> Forms are somewhat more widely deployed on the Web than fish and bicycles
> :-)
> Google would be a heck of a lot harder to use without forms. I would go as
> far as saying the Web as we know it wouldn't exist without forms. This is a
> major use case.
I don't understand this whole forms issue. I think Tim is sayign that there
is no need for a special kind of link just because it is on a form. The
semantics of a links are in the linking application, not in the XLink spec.
We are talking XML, right? If we are, then the form is likely expressed as
elements. If so, why not place the link on the elements?
> >>.. discussion on <object> with three separate linking behaviors ...
> >Indeed, the XLink encoding for that would require three subelements
> >...Why is packing it all into attributes of a single element a
> >better design?
>
> Two things: 1. In XLink, there's actuate="onRequest" and that's it. There's
> no way to distinguish between different levels of user request action, in my
> example the difference between a request to follow a link and the request to
> view longdesc information.
OK. This is one place where I can agree. I and others have complained about
the baked-in semantics of XLink, especially related to actuation. However, I
donn't see this as a big enough issue for a *W3C* WG to ditch XLink.
For one thing, you could request that the XLink WG allows a
qname-but-not-ncname value for actuate="" that allows you to do
actuate="xhtml:onRequestFlavor1"
actuate="xhtml:onRequestFlavor2"
and the like.
Heck, DAML+OIL in the case of daml:collection "hacked" RDF in the same way
without bothering to have the RDF spec changed (not that this is a practice
that should be condoned).
> 2. More generally, a common design pattern is to use elements to represent
> "things", and attributes to represent properties of those things. In many
> cases, the 'link-ness' that needs to be described is a property or
> annotation, not a thing. It should be possible to express this natural
> structure and still use links.
If this is really such a big deal, you should abandon XML altogether. After
all, many things have multiple properties with the same name. My "address" is
"Somewhere in Boulder CO" and it's also "uche a ogbuji point net" and it's
also "uche.ogbuji@fourthought.com", and "http://uche.ogbuji.net";. Attributes
won't allow me to call these all "address". So in this case, I do the
sensible sort of thing:
<person name="Uche">
<address type="mail">Somewhere in Boulder CO</address>
<address type="personal-email">uche a ogbuji point net</address>
<address type="mail">http://uche.ogbuji.net</address>
</person>
So even though the addresses are naturally properties of things, they're
sub-elements.
XML folk do this all the time without a hint of a blush (and RDF folks just
chuckle at them ;-) ). I don't see why this is such anathema to XHTML 2.0.
> >>Complex links can't nest properly
> >I wasn't aware of that, can you illustrate the problem?
>
> I was thinking of this:
> <quote cite="http://www.w3.org/TR/xlink/#extended-link";>
> Subelements of the simple or extended type anywhere inside a parent
> extended-type element have no XLink-specified meaning. Subelements of the
> locator, arc, or resource type that are not direct children of an
> extended-type element have no XLink-specified meaning.
> </quote>
>
> This would seem to preclude nested things, like the <object> tag in XHTML2.
> Even splitting out the link parts as subelements wouldn't help:
>
> object element that attempts to load a quicktime movie
> object element that attempts to load a SVG animation
> object element that loads a JPG image/
> /object
> /object
Again, couldn't you sort this out with the XLink group? What is the W3C? A
bantustan?
> Is 'xlink:href' purely an aesthetic issue? I don't know.
> But I do hear authors complain about having to type the "long" namespace
> declaration, and when they mistakenly type 'href' instead of 'xlink:href',
> unhappiness about a silent failure mode.
Oh for crying out loud. Namespaces are part of the verbose legacy of XML. We
all deal with it. Adding one namespace is a ridiculous excuse for violating
layering of XML specs.
> I see a need for something like HLink. With cooperation and a little luck,
> it can complement rather than contradict XLink.
I'm sorry, but do you guys consciously want to kill XHTML 2.0? We've all seen
the XML community separate into several cadres. the big brass types who ask
"What would BillG do", and the loud little punks who rail against anything
with the slightest establishment tincture. BTW, I've found this
characteristic split far beyond this mailing list. I had lunch this afternoon
with a successful patent attourney who surprised me by being an ardent LLP.
The WWBGD crowd isn't touching XHTML 2.0 with a ten foot pole, and the WG has
already consciously shrugged off this fact. The LLP crowd, among which I
count myself, do have some oft-stated principles, one of which is that layerd
technologies are a good thing, and that a lack of layering is reason for loud
challenge. The XHTML 2.0 spec crosses the LLP crowd as well because of its
refusal to layer with XLink. I know this makes me quite cool to it. It
doesn't help that all the technical reasons I've heard for this lack of
layering are either red herrings, or matters that should be solved by the most
rudimentary operations of organization.
--
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
|
