Re: XProc Usability (was Re: New to Xproc Question : conditionnal "output port" definition?)

Michael Sokolov <sokolov@ifactory.com> writes:

>>>      And I'm
>>>      one of the outliers who's unconvinced that moving from an XML
>>>      pattern-based syntax to a string syntax for XPath (back way before
>>>      XSLT 1.0 came out) was a good thing. Water under the bridge.
>>>
>>> Oh, wow!  The thought of that gives me shudders…
>>>
>>> I’m curious—why do you feel this way?
>> Because a lot of valuable information is locked up in a non-XML syntax
>> where I can't get at it with my XML tools. And also because XPath is
>> what introduced QNames-in-content to the world, for which sin I still
>> feel unclean.
>>
> That *does* feel to me like implementer's bias.

I felt that way *long* before I was an implementor. And it's easy to
argue that XPath (and perhaps XSLT, by extension) was successful
because it had a compact stringy syntax.

> As for the issue with QNames; I think it's unfair to blame XPath for 
> that.

I don't blame XPath for all the issues associated with QNames, I blame
it for QNames in content. Before XPath, QNames appeared in element and
attribute *names*. It was always possible to tell from the document
which namespaces were used and where.

Once QNames escaped into attribute *values* it became impossible for a
processor without special knowledge of each vocabulary to determine
which namespaces were used and where.

In moving from patterns expressed in markup to patterns expressed in
encoded strings, we (the XSL Working Group) moved QNames into content
for the first time. (At least, I think it was the first time.)

> The fact is that "names" in XML are context-sensitive and have 
> hidden parts to them which can only be detected by performing 
> tree-walking.

That's not how I see it. Names in XML are a tuple and you need both
halves. If you want to re-serialize and preserve prefixes, when
possible, they're a triple. You do not have to walk around in the tree
to find any "hidden parts". Unless, of course, you're getting a QName
From content, I suppose.

> My main beef is about the lack of default-namespace 
> binding in XPath - it's totally counter-intutitive (at least once you've 
> absorbed how namespaces work everywhere else...)

You haven't used XQuery have you? The most staggeringly awful bug in XQuery
is the fact that the default namespace binding applies to XPath expressions.
It makes code of the following form fail silently:

let $x := <nons><child>value</child></nons>
return
  <div xmlns="http://www.w3.org/1999/xhtml" class="{$x/child}"/>

You think $x/child is going to be "value", but the expression is
actually looking for child in the XHTML namespace and so you get back
the empty sequence. Totally fscking broken.

It leads to horrors like this:

let $x := <nons><child>value</child></nons>
return
  <div xmlns="http://www.w3.org/1999/xhtml" class="{$x/*:child}"/>

or extra, clumsy variables:

let $x := <nons><child>value</child></nons>
let $y := string($x/child)
return
  <div xmlns="http://www.w3.org/1999/xhtml" class="{$y}"/>

Blech.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com