Re: XInclude vs SAX vs validation

[Daniel Veillard <veillard@redhat.com>]

On Tue, Aug 21, 2001 at 05:51:39PM -0400, Simon St.Laurent wrote:
> On 21 Aug 2001 17:21:57 -0400, Daniel Veillard wrote:
> >   The implementation time and processing cost has been pointed out
> > quite a few time, I think the former is a question of getting the
> > right toolkit, if you have XPath implementing XPointer is not very
> > hard (took me too weeks part time).
> 
> While I'm delighted that there _is_ an XPointer implementation, and
> thank you for writing it, I really wish you'd stop claiming that
> "implementing XPointer is not very hard". 

 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.

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

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

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

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

> 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.
 We tried to minimize the implementation cost and amount of training needed
for users precisely by reusing XPath.

  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.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/