XPointer (was Re: XInclude vs SAX vs validation)

["Simon St.Laurent" <simonstl@simonstl.com>]

On 21 Aug 2001 18:35:27 -0400, Daniel Veillard wrote:
>  when starting from an XPath implementation, it's not. I really built
> my implementation in 2 weeks on top of my XPath toolkit and at that
> time I was still discovering XPath itself.

Many of us don't work in environments where XPath is available (SAX) and
where developing ranges over nodes is difficult.  That doesn't mean we
aren't working with hypertext, it just means that we're working with
constraints that XPointer doesn't acknowledge.  (Ditto for XPath.)

> > If it's so easy, why is genuine XPointer support such a rare creature?
> 
>  Simply that use of XML for hypertext is not widespread. Hence the
> delta from XPath (basically ranges) did not compell that many people
> to get one of their toolkit engineer to work a few weeks on it.
>  We also suffered from the existence of the Sun's patent, this problem
> certainly didn't helped, I hope this is cleared now.

There are those of us who have argued that XLink's on-again off-again
development and general overkill have hurt the use of XML for hypertext,
and XPointer has imposed similar, perhaps worse, problems for those of
us who came to XML looking explicitly for hypertext.  

> > I've implemented the (braindead simple) child sequence portion of it,
> > and I'm working on improving my support for IDs in that mix, but I can't
> 
>  Simon, just consider this last step, assume your toolkit doesn't have
> DTD parsing support and interfaces, I think that ID support would suddently
> not be the part you would have chosen to implement, right ? The cost/benefits
> in that context would seems pretty heavy. 

ID support is much easier to get out of a SAX parser than XPath,
however.  The cost/benefit situation you cite is not especially common,
and ID usage adds robustness to links rather than make them possible in
the first place.

>  What I want to point out is that it's a question of reusing previous layers
> to build the next generation tools. That's what makes tools more powerful
> and better in the end.

If those layers are present.  Not everyone shares the same set of
layers, and developing layers with dependencies on lower layers which
don't fit common constraints isn't especially friendly to those of us
attempting to implement hypertext with a different tool kit and set of
priorities.

>  I tend to compare SAX to assembly, it's blazingly fast, allow to completely
> control you data flow, etc. but what you really want is build on top.
> The gap from SAX to XPath or XPointer is probably like going from assembly
> to Lisp or Prolog, it's a lot but it should not stop people needing high
> level tools.

I don't grasp what you're saying here.  Mixing assembler and C and even
Java isn't that difficult. Supporting all of XPath in a SAX framework
seems largely impossible.

> > say that I find (or that many other people find) that "implementing
> > XPointer is not very hard."  I'm certainly not a programming wizard, but
> > I don't think I'm also in finding that implementing XPointer (as it
> > currently stands) is in fact quite difficult.
> 
>   Taken alone, XML-1.0 + DTD, was far more work to do right than
> XPath + XPointer honnestly. Still you don't seem afraid to use the former.
> Why ? I think you got used to it, you know you have tools to provide
> those if needed, etc.

I think it's what I had to work with at first, and I think the
complexity inherent in XML 1.0 is already considerably more than many
people needed.  (Note the continuing existence of SML-DEV.)

"Get used to it" isn't adequate justification for overbuilt specs to
many of us, I'm afraid.
 
> > Sadly, claims like this have a direct impact on the kind of XPointer
> > spec we're like to see emerge from the W3C.  The nature of that spec is
>      Hum I'm not sure I understand fully this sentence.

You keep repeating that XPointer is easy, while many others (think
FIXptr) have said repeatedly that XPointer is hard.  Your claims, I'd
suggest, have soothed the working group into releasing a spec that many
of the rest of us find wildly excessive, especially for a 1.0.

> > going to have a direct impact on the usefulness of XLink and XInclude,
> > and I can't say the future looks particularly bright.
> 
>  It is possible that XPointer is not the right level, well not that many
> people uses Prolog nowadays (but I'm sure I will get mails for having said
> that :-), finding the right abstraction level is seldomly reached at the
> first iteration. However in general XPath seems a success, I have been
> on the xsl-list for some time now and people seems to grasp it even if
> there is a number of strange constructs, at least the abstraction level
> seems the right one (people seems to have far more troubles with XSLT
> execution modle than the XPath part itself). And XPointer is just a 
> specialization of XPath for hypertext needs, so from the distance it looks
> like the right level for hypertext.

I have to wonder what distance you mean.  From my distance, it looks
like an enormous pileup.  There may, of course, be a glorious underlying
order to that pileup.

>  We tried to minimize the implementation cost and amount of training needed
> for users precisely by reusing XPath.

I look forward to teaching hypertext authors about XPath.  There are
tools, yes, but I can't say they're especially fun either.

>   Now finding if XPointer is actually the right level will take more
> than just implementation, it will take user trial. XInclude is IMHO 
> an excellent use to test this. Like is trying to provide hypertext tools
> based directly on XML. Getting through this trial is the only way to
> really know how far XPointer should go.

I guess we'll see what happens - I certainly have no control over the
matter - but I have a very hard time recommending the use of XInclude /
XLink / XPointer to anyone operating outside of a closed (they have
total control) environment right now, and don't expect that to change
for a long while.