W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > September 2007

Re: Comment

From: <Deborah_Pickett@moldflow.com>
Date: Thu, 27 Sep 2007 18:18:42 +1100
To: public-xml-processing-model-comments@w3.org
Message-ID: <OF7DB3669C.9D618518-ONCA257363.002268BA-CA257363.00282A1F@moldflow.com>
Hi Vasil,

Thanks for the responses to my comments.  A couple of further remarks:

I am evidently blind enough to have missed the mention of dynamic error 
XC0012 for when p:directory-list cannot run because of access 
restrictions.  (Sorry about that.)  You (and Norm) asked if there were any 
other steps missing this.  I wonder if the steps that could access a 
remote URI might come into that too, even if such access is read-only; it 
could be used for a "phone home" type message.  That makes p:load, 
p:store, p:document, and indirectly p:xinclude, p:xslt, p:xslt2, and all 
the validation steps candidates.  Perhaps others.

As for the versioning issue (that is, where is p:pipeline/@version?) . . 
unimplemented steps are the easy bit.  I'm interested more in the more 
subtle cases.  Like:
- Currently XProc uses XPath 1.0 select strings everywhere.  In a future 
XProc that will become XPath 2 or later (I hope); how do XProc instances 
ensure compatibility?
- What about existing steps that develop additional attributes in future 
versions of XProc?  Are such attributes ignored in XProc 1.0, or do they 
throw an error?

I've just noticed that the p:xslt and p:xslt2 steps are expressed in terms 
of the stylesheet, not the processor: "The p:xslt step applies an [XSLT 
1.0] stylesheet to a document." not "The p:xslt step applies an XSLT 
stylesheet to a document using an XSLT 1.0 processor." I'm assuming that 
this is deliberate.  It would explain my earlier confusion.  That being 
the case, it would be equally right for p:xslt to delegate to an external 
XSLT 1.0 processor and to an external XSLT 2.0 processor that has the 
backwards-compatibility feature.  Both would process an XSLT 1.0 
stylesheet the same way.  Am I on the right track?  (Turning that around, 
wouldn't a p:xslt2 step be allowed to invoke an XSLT 1.0 processor on an 
XSLT 2.0 stylesheet*, because XSLT 1.0 processors are required to have 
forwards-compatible processing?  I'm reading the XProc draft and XSLT 
specs and can't see the fault in that chain of reasoning, though it seems 
a tad odd.)

* Assuming no use of initial modes, initial templates, empty input 
documents and other new XSLT 2.0 things.

Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Received on Thursday, 27 September 2007 07:19:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:24 UTC