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

FW: Renamer-att (was: Can XLink be fixed?)

• To: <xml-dev@l...>
• Subject: FW: Renamer-att (was: Can XLink be fixed?)
• From: "Keith W. Boone" <keith@w...>
• Date: Mon, 26 Aug 2002 11:40:48 -0400
• Importance: Normal
• Reply-to: <keith@w...>

Arjun Ray writes:

> Very much, not to mention building in dependency on yet another spec, with
> all its own complexities and support requirements.
		:
> To put it simply, a scheme that maps one attribute to another.  Since it's
> only about mapping anyway (and *just* mapping), why can't the mechanism be
> kept simple?

Since none of use can backwards in time and change history, whatever
solution you adopt that resolves the problem will build a dependency upon
another specification.  You are correct in pointing out the complexity of
XPointer, with all of its support requirements.  However, the link() mapping
scheme I described could be that simple, and if that is all you need, then
let it be all that you implement.  I believe there is even wiggle room in
the XPointer framework to build an XPointer processor that implements only a
few schemes.

The major benefit of what I proposed is that it fits within the current
framework of W3C standards, and has some potential on its own for being
adoptable as a standard.  It is no more than a hack on XLink, just as
namespaces were a hack on XML, but it gets half the job done.  The other
half is as you clearly pointed out:

> Also, this does not remove the need for colonified names in declaration
> subsets and the associated jiggery-pokery with PEs and whatnot to make
> that "work".  That is, this proposal says nothing constructive about the
> provenance of the "xlink:" prefix in all those attribute names, which is
> after all how the connection to the "namespace" is established.

Now, I cannot seem to get rid of colonified names in the declaration subset
and use XLink at the same time without rewriting history, or at least one
specification.  That wasn't my point.  It does require that your DTD subset
define the XLink attributes, but if you accept that restriction, it is easy
enough to declare the xlink namespace somewhere as well.  The simplest way
to accomplish that would be to use a fixed namespace declarationn, as below:

<!ATTLIST img
	xmlns:xlink	CDATA		#FIXED	'http://www.w3.org/1999/xlink'
	xlink:type	(simple)	#FIXED 	'simple'
	xlink:href	CDATA		#FIXED	'#link(@src)'
		:
>

It does introduce the possibility of further naming collisions, since the
documents might already declare xlink: to be part of some other namespace,
and thus the DTD subset changes would be a non-starter.

There is also an error on my part wherein I stated that eval() would
evaluate its scheme data as an XPointer.  Really, it would need to evaluate
its argument as a URL that possibly contained a fragment identifier, using
XPointer syntax.

	Keith

• Follow-Ups:
  • Re: FW: Renamer-att (was: Can XLink be fixed?)
    • From: Arjun Ray <aray@n...>

• Prev by Date: RE: Architectural Forms revival?
• Next by Date: Re: Detection of non-Unicode characters
• Previous by thread: [ANN] XML and Web Services Connections (31 Oct- 2 Nov in Orlando)
• Next by thread: Re: FW: Renamer-att (was: Can XLink be fixed?)
• Index(es):
  • Date
  • Thread