- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 14 Apr 2010 14:47:20 +0100
- To: murray@muzmo.com
- Cc: Norman Walsh <ndw@nwalsh.com>, public-xml-processing-model-wg@w3.org
-----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