Re: generic linking

I have long been on record as opposing full XPointer.  However,
I do want to come to the defense of the Framework and Element
scheme specs now in PR.

At 10:01 2002 12 04 -0500, Simon St.Laurent wrote:
>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.

I claim the common cases are bare names and elements, and I do
not think an XPointer using the element() scheme is grotesque.

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

Where we can agree to disagree is on how much more power is needed
and where the cost (of complexity) versus benefits (of power) curve
reaches an inflection point.

I agree that one needs more than just pointing to IDs.  I believe that
one needs to be able to point to any element in a document without having
to modify the document.  I believe this is the minimum needed to declare
victory, and I believe that is simple enough so as to minimize complexity.

>If all you want is the simple cases,
>write a spec that covers the simple cases and be done with it.

I believe we did.  I believe the element() scheme is it.  It allows
pointing to any element in a well-formed XML document.

Here are some sample URI references using the framework (bare name) and
element() scheme (all using the same URI):

I find none of them grotesque.


Received on Wednesday, 4 December 2002 10:52:28 UTC