[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [Fwd: The problems with Xlink for integration languages]


Re:  [Fwd: The problems with Xlink for integration languages]
At 3:09 PM +0100 9/17/02, Jeni Tennison wrote:

>I guess that my argument would be that if you are happy for this
>restricted kind of transformation to be specified within a schema,
>then why not allow for the specification of more flexible
>transformations as well, including those that can deal with the facts
>that (a) people, it seems, want to use domain-specific terminology
>when naming attributes that hold URIs (which could be handled by an
>AF) and (b) people want to be able to specify multiple links from the
>same target without using separate elements for each of them (which
>needs something more sophisticated).

Umm, because I don't want to bother inventing yet another schema 
language? My hope is that we can make the minimal change necessary. 
Reinventing schemas to support linking is sort of like swallowing the 
spider to catch the fly, and we all know where that leads. :-)

>I'm not sure that I would really choose to specify the linking
>semantics of an element in terms of a transformation to XLink (I think
>I'd probably prefer the second of the suggestions that I made -- a way
>of annotating attributes or elements to indicate that they are links)
>but it's preferable, to me, compared to forcing users to link to or
>specify explicitly the same HLink spec from each of their HTML
>documents.

My point is that in XHTML the element name alone (possibly in 
conjunction with an xlink:href attribute) should be sufficient to 
identify an element as a link and specify the type of link. We do not 
need the ability to make any arbitrary element a link of arbitrary 
type.

XHTML 2.0 does, I think I recall, want to allow an arbitrary element 
to be a classic blue underlined link; and this can be done with the 
xlink:type attribute on an element by element basis. HLink seems to 
be identifying all elements of a certain type as links, which isn't 
really the use case. But I do need to reread the spec a few more 
times to make sure I understand it.

>Although I'd argue that it doesn't correctly reflect the semantics of
>the elements. As simple links, the source, longdesc and map elements
>are the resources which are linking to the URLs specified in their
>xlink:href attributes. I would have thought that the extended link
>semantic, which makes the alt text the local resource, is more
>accurate (though it still doesn't feel quite right, but I don't know
>how to make the object the local resource using XLink?).

Ummm, why do you say that? I think it perfectly reflects the 
semantics of the elements, at least as much as anything in XML does 
have semantics. I don't really give a hoot about local and extended 
resources and all that other extended link fru-fru. I just want to 
say here's an image, here's the description, here's the map file, 
etc. What I've realized in the last 24 hours is that we don't need 
extended XLInks, at least for XHTML. Simple links in child elements 
with well-known names work just fine, and they're much easier to 
explain to designers than either HLink or extended XLink.

To some extent this is tying back to the perennial attributes vs. 
child elements thread. Here I'm beginning to notice that maybe 
attributes never were right for a lot of the things they were used 
for in HTML. (Another example: why is ALT an attribute instead of a 
child? Linking aside, an ALT child would be very useful.)
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.