- From: Eve L. Maler <eve.maler@east.sun.com>
- Date: Wed, 11 Oct 2000 15:51:09 -0400
- To: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
- Cc: Eric van der Vlist <vdv@dyomedea.com>, www-xml-linking-comments@w3.org, www-xml-schema-comments@w3.org, Philipp Hoschka <ph@w3.org>, tbl@w3.org, danc@w3.org, dv@w3.org
At 04:50 PM 10/11/00 +0200, Lloyd Rutledge wrote:
>For example, there's the multiple URI attribute problem. Some
>elements in some formats have multiple attribute that are URI's that
>should be recognized as links. One example of this is the <img>
>element in XHTML, which has both the "src" and "longdesc" URI
>attributes. You can't just schema an xl:href on top of those
>attributes, since you can't have two href attributes in one xlink
>element. A structural transform, on the other hand, could create from
>each of the attributes a separate XLink element, and copy each URI
>attribute value to the xl:href attribute of the corresponding XLink
>element, and create whatever other attributes are needed for each
>XLink element.
For that matter, you could "harvest" XLinks from any source by generating a
third-party linkbase that describes the same arcs as in the original. For
example, you could generate an extended link that has two arcs leading from
the <img> element (where this element would be a remote starting resource
in XLink terms) and leading to the "src" and "longdesc" resources,
respectively. Given that we have some knowledge of the semantics of these
HTML arcs, you could even define RDF properties that stand for them, and
use them as arc roles in your generated linkbase.
I've been meaning to float this approach forever, but forgot about it until
just now. It would have to be tuned for each non-XLink language, of
course; it's not something that the XML Linking group could standardize.
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ east.sun.com
Received on Wednesday, 11 October 2000 15:52:15 UTC