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
>verbose:
>
> 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
tolerable.

>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
earlier:
>>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
>>possibilities.

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
event. 

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

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