Re: XProc Minutes: 8 Apr 2010

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

murray writes:

> I expected a pipeline that prescribed an order for a core
> set of XML processors, starting with well-formed xml
> processing and followed by (in some order) GRDDL
> interpretation, entity expansion, id validation, xml
> validation, namespace management, xinclude expansion,
> schemata validation and so on. I expected to have a model
> that prescribed or described when and where decryption and
> digital signature processing occur. I expected that for each
> step, the spec would provide reasoning for the position in
> the order as relates to building the infoset. I expected the
> pipeline, or library of pipelines, to provide for the
> ability to snif a document to determine whether it is
> eligible for processing, either by way of processing
> instructions a la XSLT, or through well-understood info
> items such as the GRDDL signature. 

I guess we ended up aiming _much_ lower.  Or, perhaps, tried to answer
a different question.

Question 1 (yours): My XML application requires the following processing: x,
y, z, p, q, r, . . .  In what order should I apply them?

Question 2 (the draft's): My XML application starts from an
infoset/data-model -- what should I say about how it gets built?

> [C]onceptually, are my expectations too great?

No, just different.

Perhaps we're just guilty of the Drunk and the Lamppost syndrome: we
know how to answer the question 2 in a simple way that we suspect/hope
there will be general agreement with and uptake of.

In contrast I personally don't see an answer to question 1 which will
be simple and attractive enough to get traction.

The best I can do for a more principled justification is to appeal to
two principles to end up at the minimal position we've arrived at:

 1) The operations involved have to be completely
    application-vocabulary neutral, they address only the question of
    "what is the information content of this document";

 2) The operations involved must be fully self-contained and
    automatic, that is, not requiring parameterisation or user
    interaction.

(1) rules out GRDDL interpretation or xml-stylesheet application; (2)
rules out decryption and signature verification, and arguably
validation as well.

Not sure what the right answer is here. . .

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)

iD8DBQFLxcdokjnJixAXWBoRAsZVAJ93F7kMFaDLyA6bKTCKutWIBKTD2gCeNoCA
QXLMAGpXL002DbgF1hOZrXg=
=V4Qc
-----END PGP SIGNATURE-----

Received on Wednesday, 14 April 2010 13:48:08 UTC