[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
>if HTML wanted to add links with multiple ends, or which could be out of
>line, or could have some simple behaviors, why invent your own rather
>than adopt XLink? The question is serious, not rhetorical. -Tim
I wonder what Tim and others think about this: Would it make sense for XHTML
to use XLink for only some things but not others? Or would it make more
sense to use XLink "across the board"?
Seems both the "economy of scale" and "ease of authoring" arguments tend to
converge on the latter. If that's the case, then I want XLink 2.0, or HLink,
or whatever (I ultimately don't care what it's called or who's responsible
for writing the spec) to be a fully general purpose linking that works in
any XML user vocabulary--especially XHTML.
Thus, some of the XLink/XHTML interactions I talked about in an earlier
message can be distilled down to the following requirements for a future
spec:
1. XLink 2.0 must provide extensibility to represent linking scenarios not
covered by XLink 1.0.
For example, it's not clear how the following could be recast to use XLink:
<xhtml:form action="http://submit.example.com"; method="post">
<!-- form submission is a link, sort of -->
or
<xhtml:object href="http://link.example.com";
longdesc="http://desc.example.com"/>
<!-- two different variations on 'onRequest' activation -->
In general, any attempt to describe every possible value for show, actuate,
etc. will be incomplete, so the specification needs to define an escape
hatch along with well-defined semantics.
2. XLink 2.0 must minimally constrain XML vocabulary authors.
Creating a markup language is huge balancing act, and adding additional
constraints tends toward making the job impossible. Specifically,
* XLink 2.0 must neither mandate nor forbid the use of element or attribute
constructs to define links
* XLink 2.0 must support any number of links on a single element
* XLink 2.0 must support links on arbitrarily nested elements
* XLink 2.0 must work with user-visible element and attribute names of the
host language's choice
This is oft described as 'xlink:href' vs. 'href', but that trivializes a
legitimate problem.
- Naming conventions or common sense might dictate different attribute
names, like 'action' for forms.
- The host language might not use English, or might not use western
characters. (this is really just a restatement of the previous bullet)
- The attribute in question might need to be namespaced for some other
reason
- One view is that proper layering dictates that function doesn't force
itself into the user-syntax. (People in this camp also tend to disapprove of
xsi:type)
- Providing back-compatibility with XHTML 1.x gives an immediate large
document base, which will help bypass the chicken-and-egg problem of the
lack of generic XLink processors.
- Compared to solving the first three * bullets above, this one's a
cakewalk. It might even just fall out of the solution.
Thanks,
.micah
|
