[
Lists Home |
Date Index |
Thread Index
]
From what I understand, one "problem" is that xlink requires the use of the
Xlink namespace on href and type, and that others want to "have there cake
and eat it too", without having to use the XLink namespace [or at least
without having to write with it]. Folks would also like to be "backwards"
compatible with other markup languages [i.e., XHTML], so that attributes
like a/@src can also be used as links.
Now, assuming that xlink:href values are expressed as XPointers, define a
scheme for the XPointer framework called eval(), which evaluates the
XPointer Expr [just as xpointer() does], but then further evaluates the
string value of the result as an XPointer Expr.
So now, you could define the xlink attributes on img to be fixed, as
follows:
<!ELEMENT img EMPTY>
<!ATTLIST img
xlink:type (simple) #FIXED 'simple'
xlink:href CDATA #FIXED '#eval(here()/../@src)'
:
>
Which then means that:
1. You can write src='whatever', and have it be evaluated as you would
expect.
2. You don't have to write xlink: if you don't want.
3. You don't have to change the XLink standard, just the XPointer one,
which isn't quite done yet, and has this provision for extension by new
schemes which means that even when it is finished, it can still be extended.
Now arguably, eval() is overkill to solve this problem. Since most use
would simply be in the form '#eval(here()/../@src)', you might define a
scheme named link(attr), whose argument is the name of an attribute. Then
instead of #eval(here()/../@src), you could say #link(src).
Anyway, it's just a thought.
Keith
|
