Re: generic linking

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

Yes, I disagree.  I don't believe that you can make a case for
XPointer's current form based on the 'common cases', which in any case I
don't believe to be as common as you seem to think.

>For imaginable, but not yet real cases, XPointer could be irritatingly
> xmlns(a=URI) xmlns(b=URI) xmlns(s=URI)
> s:schemeName(a:foo/b:bar{s:dwim})

If I could abbreviate all my URIs to three letters, that might be

>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),

That extrapolation strikes me as quite simply wrong.  As I noted
>>XML has a much rougher time with that, in part because of the issues
>>around barename references and in part because XML's combination of
>>structural clarity and semantic openness open a lot more

IF most XPointer work uses IDs, then XML fragment identifiers will look
much like HTML fragment identifiers, and all will be fine.  I do not
expect that to be the case for nearly every circumstance where
developers needed something more powerful than HTML in the first place,
and I don't see a lot of people whose scope of work is similar to that
of HTML developers using XML in this way.

>is the additional complexity required for the complex cases really too
>large a burden to bare for the simplicity of the easy case?

I think that's the wrong question.  If all you want is the simple cases,
write a spec that covers the simple cases and be done with it. URI
references may not be an appropriate medium for the complex cases in any

Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down! --

Received on Wednesday, 4 December 2002 10:01:22 UTC