XProc LC Disposition of Comments

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

available for review.  Mostly editorial changes.  Only changes since
previous draft have been highlighted in the diff version.

  http://www.w3.org/XML/XProc/docs/xml-proc-profiles.html
  http://www.w3.org/XML/XProc/docs/diff.html

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMmkRqkjnJixAXWBoRAvaYAJ0RiPQtjHXx8cGXcHJBEI4z7SYXUwCeJcZC
2+BX4382A61apHRQimcqHQU=
=2Qrc
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I keep writing lots of little steps to build and insert fragments or
to restructure things.  I think I want the equivalent of a single
template + copy-all template stylesheet, something like

 <p:template match="...">
  [XML goes here, with {} interpreted in both attr vals and text content,
   and something like <c:copy select="..."/> recognised]
 </p:template>

This would allow the following simplifications (drawn from real
examples):

 Replace

  <p:insert position="first-child">
  <p:input port="insertion">
   <p:inline><Timestamp><here/></Timestamp></p:inline>
  </p:input>
 </p:insert>

 <p:string-replace match="mt:Timestamp/mt:here">
  <p:with-option name="replace" select="concat('&quot;',$stamp,'&quot;')"/>
 </p:string-replace>

 with

 <p:template match="/top">
  <top>
   <c:copy select="@*"/>
   <Timestamp>{$stamp}</Timestamp>
   <c:copy select="node()"/>
  </top>
 </p:template>

Replace

  <p:add-attribute match="c:request" attribute-name="href">
   <p:with-option name="attribute-value" select="*/@uri"/>
   <p:input port="source">
    <p:inline>
     <c:request method="GET">
      <c:header name="Accept" value="application/rdf+xml"/>
     </c:request>
    </p:inline>
   </p:input>
  </p:add-attribute>

with

 <p:template match="/*">
  <c:request method="GET" href="{@uri}">
   <c:header name="Accept" value="application/rdf+xml"/>
  </c:request>
 <p:template>

Replace

  <p:add-attribute match="/*" attribute-name="set">
   <p:with-option name="attribute-value" select="$set"/>
  </p:add-attribute>
  <p:add-attribute match="/*" attribute-name="group">
   <p:with-option name="attribute-value" select="$group"/>
  </p:add-attribute>
  <p:add-attribute match="/*" attribute-name="test">
   <p:with-option name="attribute-value" select="$test"/>
  </p:add-attribute>
  <p:add-attribute match="/*" attribute-name="validity">
   <p:with-option name="attribute-value" select="$validity"/>
  </p:add-attribute>
  <p:add-attribute match="/*" attribute-name="x:outcome" xmlns:x="x">
   <p:with-option name="attribute-value"
                  select="if ($validity=$expected) then 'win' else 'lose'"/>
  </p:add-attribute>

with

 <p:template match="/top" xmlns:x="x">
  <top set="{$set}" group="{$group}" test="{$test}" validity="{$validity}"
       x:outcome="{if ($validity=$expected) then 'win' else 'lose'}">
   <c:copy select="@*|node()"/>
  </top>
 </p:template>
 
A richer and simpler approach would be to follow Richard Tobin's lead
in one of our Edinburgh XML tools, and interpret the contents more
along the following lines:

         [interpreted as if] an XSLT template which is used to
         construct the replacement for matched nodes.

         In the stylesheet, the prefix xsl is bound to the XSL namespace.
         A low-priority template rule is included that provides an
         identity transform for nodes not matched by the template. For
         convenience, a number of entities are defined for use in the
         template:

         &this; Copies the current node and recursively processes its
                attributes and children. Equivalent to
                <xsl:copy><xsl:apply-templates select=?@*|node()?/></xsl:copy>.

         &attrs;
                Processes the attributes of the current node. Equivalent
                to <xsl:apply-templates select=?@*?/>

         &children;
                Processes the children of the current node. Equivalent to
                <xsl:apply-templates select=?node()?/>.

         &text; Copies the text of the current node. Equivalent to
                <xsl:value-of select=?.?/>.

         &space;
                Inserts a space character. Equivalent to <xsl:text>
                </xsl:text>.

         &newline;
                Inserts a newline character. Equivalent to
                <xsl:text>&#10;</xsl:text>.

This would give

 <p:template match="/top">
  <top>
   &attrs;
   <Timestamp>{$stamp}</Timestamp>
   &children;
  </top>
 </p:template>

instead, or, if we took the above literally and didn't mess with {},

 <p:template match="/top">
  <top>
   &attrs;
   <Timestamp><xsl:value-of select="$stamp"/></Timestamp>
   &children;
  </top>
 </p:template>

and so on.

Either approach would obviously be even more useful if/when we allow
node-valued variables.

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMZBufkjnJixAXWBoRAulEAJ48QTA79US7u+rUhBF1eAUpLpjrbACfS3om
/qTJGnZVd2506cZJHVbE4CE=
=7I1P
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Consider the following URI:

  http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.xml#element-key

In Firefox 3.6pre, IE8, Chrome 5 and Opera 10, it just works.

But there is _no_ justification for this, in 3023 or 3023bis.  Why?
Because there is no ID with value 'element-key' in the XML document
identified by the above URI.  It exists _only_ in the output of the
XSLT stylesheet named in an xml-stylesheet processing instruction
which appears therein.

Or so it seems to me.

I think we need to add this to the use cases on the table as we
consider the TAG's request [1] to think again about generic processing
and frag-ids.  I'm tempted to say that we need to find a way to allow
application-specific frag-id semantics to co-exist with generic
semantics.

One subsidiary question -- is this or is this not a "same-document
reference" [2]?  Or, to put it another way, where if anywhere do we
find a definitive answer to the question of what the base URI is of
the _output_ of an XSLT stylesheet applied in these circumstances?

ht

[1] http://lists.w3.org/Archives/Public/www-tag/2010Jun/0125.html
[2] http://www.apps.ietf.org/rfc/rfc3986.html#sec-4.4
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMI2ZvkjnJixAXWBoRAl2PAJ9idoD6tdM1NYnFmFh9m5re4WySSgCbBn2A
KnLZSKkCbdKkd9ELoR1dYPQ=
=OOr/
-----END PGP SIGNATURE-----