Re: Generic link handling

Hash: SHA1

/ "Simon St.Laurent" <> was heard to say:
| It may be time to seriously reconsider URI references and their proper
| role in linking.  While I have few qualms about using URIs as part of a
| Web-oriented linking structure, we need to ask some hard questions about
| what part URI references should play.

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.

| In dealing with XPointer, I often feel that it's the result of some
| basic mistakes in XLink, and that, much as Ann suggested, the game of
| chess has been redefined so that the queen moves like the rook. 

The most recent XPointer drafts don't seem too bad to me [fair
disclaimer: I helped write them so I may not be unbiased :-)].

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.

                                        Be seeing you,

- -- 
Norman.Walsh@Sun.COM    | Vision is the art of seeing things
XML Standards Architect | invisible.--Swift
Web Tech. and Standards |
Sun Microsystems, Inc.  | 
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <>


Received on Tuesday, 3 December 2002 13:40:48 UTC