[
Lists Home |
Date Index |
Thread Index
]
Hi Elliotte,
>>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 suggesting inventing another schema language, in fact I'm
arguing against inventing another schema language (which is what HLink
is, I think) and for taking advantage of the extensibility of existing
schema languages by defining schema adjuncts that can identify what
elements are links and/or taking advantage of existing transformation
languages (e.g. AFs and XSLT) in order to describe mappings from one
existing markup language (XHTML) to another (XLink).
But perhaps you understood that and are saying that defining schema
adjuncts constitutes defining a new schema language? I guess you could
see it like that -- certainly it involves inventing *something* new to
deal with the problem of working out which elements are links.
>>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.
Sure, although in the wider case than XHTML that *is* a requirement
because you can't assume that applications will have built-in
knowledge of every arbitrary XML element.
>>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.
Err, OK. I thought that you'd want to say "here's an image, here's a
description of the image, here's a map file of the image, here's the
alternative text for the image" -- in other words that it's somehow
important conceptually that the src, description, map and alt are
describing the same *thing*.
Or if you want to think behaviourally, I thought it was important that
the description appeared when you right-clicked on the *image*; that
certainly seems more useful than having some empty text that you can
click on to go to a description.
I thought that the point of extended links was to support these kinds
of functionality.
> 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.
I certainly agree that simple links are much easier to explain to
designers than either extended links or, I imagine, HLink.
> 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.)
Ahh yes, if only we had a markup language where you could annotate
annotations... but that's another topic.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
