Re: Xpointer

At 01:17 AM 2002-08-05, Charles McCathieNevile wrote:

>IDs are normally the most robust things over changes. So an Xpointer tool
>could check for an ID and ask if there was any reason not to use it...

Is this really true?

Where the pattern one wishes to persistently access is "the introductory
subsection in the conformance section of the document" it is likely not.

An example where an ID would be an inferior reference is the example from the
RFB&D website where, for dyslexic accomodation, they were putting the first
word of a paragraph in one step larger font and the first letter of that
word in yet a larger presentation.  But this was all position-in-paragraph
in its sense.  For this, a contextual pattern is the more stable or persistent
reference to what is the matter at hand.

Relatives of the 'first-letter' pseudo-property are better referenced by 
pattern than by atomic ID.

The use of relative URLs is analogous.  Relative-role patterns are the highest
and best expression for some references.  It is not possible in general to say 
#id references are always better.

They are better as of now in terms of down-level compatibility.  This alone
argues for the authoring technique as a transitional measure. 

An authoring technique that offers the ID as a reference handle where there is one
does not have to be wired into the framework for XPointer.  It can be tried and
be deployed on its own merits independently.

So far, The argument from general Web quality is debatable, and the argument
that there is an access dependency even weaker.  Can someone explain why this 
technique should have standing to be a WAI issue against the pointer framework.

There are competing optimizations to be looked at, not a true generic preferece.

Binding associations as locally as possible, in as context-independent a way as
possible, is good for resource reusability by cut and paste.  But there are
processing reasons for define-before-use rules and getting things in the processing
pipe associated to the root of the scope where they are generally available.

The canonical form of reference includes acceptors articulating conditions on the context,
and not just an identity of "a thing."  The latter is efficient where it works, but
we are as dependent on the fact that it doesn't always work as we are dependent on
its advantages when it works.

Al


>On Mon, 5 Aug 2002, Nick Kew wrote:
>
>>Charles, have you been looking at my new EARL[1] stuff, or are we just
>>thinking in parallel?
>
>Nothing parallel about it. I'm shamelessly following on from your ideas.
>
>>
>>It is indeed possible for a tool to generate its own IDs for every
>>node in a DOM, and use these internally to reference them.  An EARL
>>tool can also export them, provided it makes available the IDs themselves
>>(as in my latest tool[1]) and/or machine-readable instructions for
>>reconsructing them as previously discussed ([2], etc).  The former
>>simplifies a document snapshot, whereas the latter is still
>>necessary if we want rubustness across document changes.
>
>I'm looking at the simple case where an Xpointer constructed by counting
>elements or something points to a thing with an ID already. (if the tool
>constructs an ID it is not certain that other tools will have this available
>to refer to without having an agreed way of assigning ID, and that gets
>circular...)
>
>IDs are normally the most robust things over changes. So an Xpointer tool
>could check for an ID and ask if there was any reason not to use it...
>
>Chaals

Received on Monday, 5 August 2002 08:22:05 UTC