xml-dev - Re: Mapping XHTML to XLink via Architectural Forms

[Jonathan Borden <jborden@mediaone.net>]

Simon St.Laurent wrote:

> At 06:47 PM 10/26/00 -0400, Jonathan Borden wrote:
> >I read the proposed 'solution' to the problem of XHTML etc links and
> >compatibility with XLink (http://www.w3.org/TR/xlink-naming/).
> >
> >XHTML 1.0 is specified via DTDs as is XHTML 1.1. XLink needs to support
this
> >W3C recommendation in its current form. Architectural Forms would be a
> >fairly straightforward way to solve this problem (and perhaps one of the
> >best use cases for AF I've seen -- IMHO).
>
> I think that's a lot of what was intended in the early drafts of XLink:
> http://www.w3.org/TR/1998/WD-xlink-19980303#remapping
>
> When the attribute remapping was dropped in favor of namespaces, new kinds
> of conflicts emerged.
>

    Sigh. Have any of you tried to rearchitect a piece of software for
"version 2", spending XXX amount of time rewriting everything, then finding
some problems at a late stage, requiring another rewrite and finding
yourself essentially back at version 1?

    In general I've been a fan of XSLT for transforms and namespaces for
namespacing, with the general opinion that architectural forms are not
general enough to do real transforms (i.e. real rearchictecting) and too
much work for namespace segregation.

    On the other hand if what we need to do is 'in-place' renaming of
attributes (or elements for that matter) so that <a href="...foo"> becomes
<a xlink:href="...foo"> AF is the easiest (and thus in my book best) way to
accomplish this, with the strong added benefit that it is already specified,
standardized and implemented.

    It is looking like the W3C process is in a logjam of interlocking
problems whose solutions are being proposed for later specifications which
themselves are interdependent on prior specifications which aren't yet out
of the CR phase because ... (y'all get the drift).

    The way to proceed in this situation is to step back, support current
recs, and bring in modularized and working solutions i.e. why reinvent AF
when it already exists? This process can be orthogonal to XML Schema based
type specification, which as has been pointed out will require an API (e.g.
DOM Level 5 or XSLT 2 or SAX 3) to be useful, thus standing people who have
now already been waiting ***years*** for XLink to become a REC. And if XLink
is going to require some future mod to XML Schemas and a new as yet
unspecified API, remind me how this is a simplification of HyTime?

    So, let's get off our duffs and insert a simple solution that is already
an ISO standard and works for the task at hand (noting that this solution in
no way interferes with a future type specification mechanism).

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org