[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink resource confusion (long)
Eve > This definition was written to accommodate the situations of both > simple and extended links. In a simple link, the linking element > itself is a local resource that serves as the starting resource > for the one built-in arc created by that link. In an extended > link, the resource-type element is a local resource that serves, > in some set of arcs in that link, as the starting resource. Yes, this is clear. It is also a problem. The spec says (http://www.w3.org/TR/xlink/#simple-links): "The purpose of a simple link is to be a convenient shorthand for the equivalent extended link." However, by the reasoning you have given above (which i believe reflects the spec), this is not possible. There is no "equivalent extended link". Consider this example: Example 1.a: Simple link -------------------------- <section id="sec1" xlink:type="simple" xlink:href="http://www.someplace.org/something.html"> <title>Que se yo?</title> <par> No hay nada de interes en este parafo. </par> <list> <item>Nada</item> <item>Aun menos</item> </list> <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. --> <par> Esto es aburrido. Y ademas, faltan los acentos. </par> </section> This is a simple link. It has: - One remote resource. The location of the remote resource is given by the xlink:href attribute. - One local resource. The 'section' element and all its contents. Example 1.b: Extended link ---------------------------- Convert this to an extended link by adding a locator as a child of 'section' and changing xlink:type of 'section' to 'extended'. <section id="sec1" xlink:type="extended"> <loc xlink:type="locator" xlink:href="http://www.someplace.org/something.html"/> <title>Que se yo?</title> <par> No hay nada de interes en este parafo. </par> <list> <item>Nada</item> <item>Aun menos</item> </list> <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. --> <par> Esto es aburrido. Y ademas, faltan los acentos. </par> </section> Easy. But not equivalent to the simple link from which it was derived. The simple link has: - One remote resource - location indicated by the xlink:href attribute of 'section'. - One local resource - itself. That is, the whole of 'section', including its attributes and all of its contents. The extended link has: - One remote resource indicated by the locator 'loc'. - No local resource at all. (At least as i read it.) This is not only not equivalent to the simple link in Example 1.a, it is also of doubtful utility. So, what do we do? Example 1.c: Extended link with 'resource' elements ------------------------------------------------- We can add xlink:type='resource' to the contents of the extended link. <section id="sec1" xlink:type="extended"> <loc xlink:type="locator" xlink:href="http://www.someplace.org/something.html"/> <title xlink:type="resource">Que se yo?</title> <par xlink:type="resource"> No hay nada de interes en este parafo. </par> <list xlink:type="resource"> <item>Nada</item> <item>Aun menos</item> </list> <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. All these also have to have xlink:type="resource". --> <par xlink:type="resource">> Esto es aburrido. Y ademas, faltan los acentos. </par> </section> [Note: Arcs are not shown for reasons of clarity. They are not the issue here and would clutter without aiding understanding. I'm also leaving out other non-essentials such as xlink-defined titles.] However, this is still not equivalent to the simple link in Example 1.a. The extended link now has: - One remote resource indicated by the locator 'loc'. - Four local resources specified (plus however many more 'par', 'list' etc. elements there are in the 'section'). Note also: - None of them correspond to the local resource in Example 1.a. - The linking element ('section') is no longer a resource, which means we 'lose' its name and attributes. This is not the same as Example 1.a. It is not what i want, nor is it something that i am likely to want. What i want is what i've got in the simple link in Example 1.a, namely one local resource taken as a whole, which is conveniently divided up into paragraphs, lists, tables, and so on according to its own purpose, not the purpose of the link. Dividing this resource into its constituent parts should be for me to do or not as i see fit (or of course, a particular application). It is not something that i want XLink to do for me, or to force me to do. It is also a pain to have to add all those 'resource' attributes, especially since they don't do what i really want anyway. I don't think it's particularly eccentric of me to want to link my 'section' element as it is to another (remote) resource. This is a useful thing to be able to do. Others may disagree, but i think it would be more useful in this case and in many others than what i have in Example 1.b or Example 1.c. So, i could use simple links in cases like this. However, what do i do if i need to use an extended link because i've got TWO remote resources i want to link? Example 1.d: Extended link, no local resources ----------------------------------------------- I could use an extended link with no local resources. <!-- Somewhere in the same document. --> <ref xlink:type="extended"> <loc xlink:type="locator" xlink:href="#sec1"/> <loc xlink:type="locator" xlink:href="http://www.someplace.org/something.html"/> <!-- Other locators to remote resources not shown for clarity and simplicity. --> </ref> <!-- Somewhere else in the same document --> <section id="sec1"> <title>Que se yo?</title> <par> No hay nada de interes en este parafo. </par> <list> <item>Nada</item> <item>Aun menos</item> </list> <!-- Lots more 'par', 'list', 'table', 'figure' elements etc. --> <par> Esto es aburrido. Y ademas, faltan los acentos. </par> </section> This is better, but still not what i had with the simple link: - The previous remote resource is still a remote resource. - The previous local resource is now a remote resource. [Note: The previous link element (Example 1.a) is no longer a link element. This is not a bad thing in itself- just so we are clear.] In many cases this could be a useful alternative. However: - Dissociated (if i may use this term) extended links are more complex to deal with. - I may not want to create extended links which have nothing to do with the material and serve only to link. They are more intrusive on document structure than simple links, and possibly even extended links which are not dissociated in this way. I should be able to move between simple and extended links without a radical change in meaning and use when everything else is the same. After all, the meaning and use of the document is more important than the meaning imposed by the link, and should not be interfered with by the link, if at all possible. So, what i want is to be able to have the simple link nature (the link element and its content are the local resource) with extended links (with adjustments so that locators are excluded). OTOH, being able to have multiple local resources enclosed in an extended link can also be useful. We do want the ability to group related but distinct local resources in links. Nevertheless, i think this may be a less common requirement than having a "whole resource" which we want to preserve as such. Of course, what i think i'd use more often may not be right for others. > > - Is this optional? Do we get to choose? > > Nope. Well, actually, i didn't really think we had a choice here. (Note to self - Forget the irony, unless you're prepared to use smilies.) > This is the correct one. But note that xlink:type="title" > has no particular meaning inside simple linking elements. There is no xlink:type='title' in my example. The 'title' element is the title of the paragraph, not the link. > You could use an extended link and create a remote resource that > points back into the par element, if you want, but that's going > kind of far. Could be done but may be inconvenient. See comments on Example 1.d. > If you're only interested in the text content of > an element, your traversal/rendering process would surely take > that into account. No, i don't want to mix link structure and traversal/rendering in any way if i can avoid it. I don't think it's a good idea to rely on some expected processing to make up for inadequacies in link structure. Similarly, link structure should constrain link use as little as possible. > (You probably want one or more arc-type elements in here too, but > maybe not because you could be intending to use the default of > "arcs between everything.") Ah! Thanks for that. I wondered what the default was. It's probably mentioned in the spec, but i'm a bit spec-blind now. As i mentioned above, i'm ignoring arcs here in order to avoid clutter in the examples and discussion. > Correct, unless you define a locator-type element that points > back into the linking element, the title element, the content > of a particular other subelement in there, etc. This might be > considered "stupid pointing tricks," or it might be something > really clever. :-) Not stupid. Possibly inconvenient. The ability to do these kinds of tricks adds a great deal of flexibility to XLink, and i think a lot of us will be resorting to them some time or other. > I hope this helps... > > Eve Yes, but not there yet. David Jackson
|
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
|