XLink 2.0 Requirements
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
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