Re: [xml-dev] (In)Validate My Assumptions on Linking.

[Jon Noring <jon@noring.name>]

Melvin Chin wrote:
> Ben Trafford wrote:

>> Because there are dozens of different ways to declare a link in
>> different XML applications. DocBook does it differently than XHTML,
>> CML does it differently (and for different purposes) than DocBook,
>> etc. ... As soon as we specify links via a rigid vocabulary that
>> must exist in the markup, we lose interoperability between
>> different XML applications.

> I see where you're coming.  I was looking at your suggestion of
> requiring XML representation from the point of view of practicality.
> With my comment to subsequent point in mind, a link is needed if it
> is needed by data processing or representational demands due to
> inherent need of the problem.  But if a link is need only if in a
> specified format, eg. XML format, then its applicable usage would be
> much more specialised... [snip]
>
> Ok, if you're talking specifically about XLink, I'll ask if another
> worthy candidate of equal generality in application areas and
> flexibility is available as an alternative for this "data about
> relationships" representation.  If so, we can compare merits and
> pick the better or best one and refine it.  If not, then XLink would
> be the only default best candidate and it would be better to channel
> energy to make it "cover the necessary aspects" that you're
> concerned with.

I've been following this thread with great interest. Like Ben, I'm
involved in projects focused on the use of XML to represent digital
publications such as books, periodicals, etc. These digital
publications will include hypertext links and embedded objects.

And we are both interested in how one can enable XML-based publication
frameworks (exemplified by OEBPS and the proposed OpenReader) to allow
publishers to use "roll-their-own" XML vocabularies to represent
textual content.

This issue goes beyond just hypertext linking and digital object
inclusion. A perusal of the (relatively) semantic-poor XHTML
vocabulary shows various semantics we'd like to recognize in arbitrary
XML markup. And if we look at the semantically-richer TEI and DocBook
vocabularies, the list of possible semantic items greatly expands.

The accessibility community is also very interested in this topic --
in a nutshell, the accessibility community is scared stiff of allowing
"arbitrary" XML markup in digital publications until some required
mechanism is designed so the semantics of arbitrary markup (at least
semantics of interest to the accessibility community) can be
"communicated" to user agents.

[For example, the accessibility community would like to know if
certain content is an abbreviation (XHTML <abbr>), a quote (XHTML
<blockquote> and <q>), some type of computer code fragment (XHTML
<code>, <var>, etc.), and so forth.]

Based on this, I propose a two-tier approach:

1) The semantics of markup is specified in a special XML document
   which I have previously described and dubbed the "Rosetta Stone".
   Obviously not all semantics can be recognized, but those which are
   of interest to the accessibility community and other important
   stakeholders. In addition, with proper design of the "Rosetta
   Stone", the list of semantics can be carefully expanded over time.

2) Where needed, special stuff is added to CSS so publishers may
   override the default presentation for the recognized semantic items
   specified in the Rosetta Stone. This might be needed for hypertext
   linking and object inclusion, which Ben is working on.


Just some thoughts.

Jon Noring