Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XHTML 2.0 and the death of XLink and XPointer?
 > 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@f...", 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
