[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XLink 2.0 Requirements

xlink 2.0
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

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 -->
<xhtml:object href="http://link.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
- 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
- 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.




Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.