W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

Re: Generic link handling

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 03 Dec 2002 17:31:10 -0500
To: www-tag@w3.org
Message-ID: <873cpe68gh.fsf@nwalsh.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ "Simon St.Laurent" <simonstl@simonstl.com> was heard to say:
| Norm Walsh writes:
|>People really seem to want to jam all this stuff into a single string,
|>for which a URI reference (especially given the fact that the thing
|>you're pointing to is usually identified by a URI) seems like a
|>convenient starting point.
|>
|>The desire to shove these things into strings has never resonated with
|>me. I think the XSL WG made the wrong design choice back in '98 when
|>we adopted the string form of XPath. C'est la vie.
|
| I think we're in agreement on technical matters up until that last
| "C'est la vie."

That comment was directly specifically (and exclusively) at the
string-based syntax of XPath. I think that chapter is closed.

| The XLink WG seems poised to rush
| a late-changing and pretty grotesque XPointer spec out the door before
| it passes into oblivion.  

In my message, I went on to say:

  Pointing into an XML document with #barename to get to an ID looks
  like a pretty reasonable generalization of the meaning of #barename
  that everyone's familiar with from HTML.

  The scheme system seems to strike a reasonable balance between
  extensibility and verbosity. Using #element(/1/2/3) isn't so bad.

  It's unfortunate that the in-scope namespaces are forbidden from
  playing a part in the XPointer. I'm not sure that's the right
  decision, but I understand it.

So I'm saying that the XPointer specs aren't all that grotesque for
the common cases. Do you disagree?

For imaginable, but not yet real cases, XPointer could be irritatingly
verbose:

  xmlns(a=URI) xmlns(b=URI) xmlns(s=URI) s:schemeName(a:foo/b:bar{s:dwim})

but if 99% of the time XPointers are going to be used to point to IDs
in XML documents (that may or may not be true, but one could
extrapolate that that is the case from existing evidence on the web),
is the additional complexity required for the complex cases really too
large a burden to bare for the simplicity of the easy case?

| It's my hope that the rest of the XML community will think hard about
| what it really wants from hypertext linking before it too blesses these
| unfortunate specifications.  So far, I've seen no rush to reach a
| conclusion, so there may yet be time.

I think there's time and opportunity to reach a solution that's
superior to what we have now. If nothing else, the recent controversy
has returned linking to the limelight where it can be actively
discussed and the merits of different technical solutions can be
explored again by everyone still interested in the problem.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | We learn from experience that not everything
XML Standards Architect | which is incredible is untrue.--Cardinal De
Web Tech. and Standards | Retz
Sun Microsystems, Inc.  | 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE97TCuOyltUcwYWjsRAvyFAKCV8b4Y+F/p2E3LufmZevXoH45B0gCdHTyt
Nof1v29EbkPqGompZakl7Lw=
=aEPk
-----END PGP SIGNATURE-----
Received on Tuesday, 3 December 2002 17:32:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:14 GMT