- From: Norman Walsh <ndw@nwalsh.com>
- Date: Mon, 12 Nov 2007 10:22:49 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2d4uftrna.fsf@nwalsh.com>
Our meeting was entirely driven by the last call issues list. Various
scheduling conflicts meant that the attendence was somewhat spotty.
These notes constitute the closest thing we have to minutes.
Comment numbers refer to the numbers in
http://www.w3.org/XML/XProc/2007/09/lastcall/comments
Comment 13:
4. MUST not fail on standalone, well-formed XML. MUST not fail for
valdation errors. It's implementation-defined whether processing
is DTD-aware or not. MUST NOT perform other processing, such
as expanding XIncludes.
5. See 11 (and issue 70).
6. Delete should say it deletes the subtree; our match patterns can
contain variable references; editor to salt to taste.
7. Editor will fix
8. Oops, rename to match. At the top of section 1, introduce the notion
of select/match and the micro-operations as a group. Each node in the
document is considered the context node and the operation is performed
if the match is true.
9. Editor fix.
10. ACTION: Alex to draft improvements as necessary
11. While we acknowledge that you can do a replace or a delete with viewport,
we think that the language is easier to use and understand if we provide
atomic steps for common cases. And we believe that replace and delete
are among the common cases.
12. Encoding comes from content-encoding. What we typically call
"encoding" is actually the charset parameter to the content-type.
We have to specify which wins when there is an XML declaration which
specifies a different charset.
Yes, it is parsing, but "p:parse" sounds an awfull lot like p:load.
Unescape-markup really doesn't sound like loading. And it's parallel
with escape-markup.
13. Editorial
14. Change "intervening nodes" to "intervening, non-matching nodes"
Match should match only element, text, PI, and comment nodes.
15. Punt! Subsumed by a comment from XSLT WG.
16. Delete "; transformations that use non-XML ..."
17. Add assert-valid to schematron
18. Resolved.
19. Some discussion of the various options.
method-of-invocation=type-driven, element-driven, lax-wc, strict-wc
validation-root is document element
schema-construction
- honor schema location hints?
- dereference namespaces?
- allowed to consult anything other than specified schema documents
result assertion
ACTION: Henry to consider the options p:validate-with-xml-schema should have.
Consider how to specify which combinations of options may raise
dynamic errors.
20. Add a p:psvi-required option to p:pipeline. The default is no, it's
a dynamic error if it's yes and it's not supported.
21. We need to consider (a) and (b); Alex will take a look
ACTION: Alex to investigate XQuery step
22. (a) they have different base URIs
(b) bind the source to p:empty
(c) they're strings
(d) yank the default-collection option
23. Right. Fix that.
Comment 14:
- Dynamic
- Yes
- Static
- Dynamic
- You could do it, but we're not adding a step for it
Comment 15
If the href attribute of a p:import statement has a URI that begins
http://www.w3.org/ns/xproc/ then it may declare atomic steps in the p:
namespace. A processor that recognizes that URI may choose not to read
it.
It is a static error if a pipeline contains a step that isn't
declared. Consequence: you cannot write a backwards-compatible
pipeline that includes a new compound step.
It is a dynamic error to attempt to evaluate a step for which you do
not have an implementation.
Ignore unknown options in the forwards-compatible case
Changed signature counts as a static error (except for optional options)
we won't make backwards-incompatible changes to steps without changing
their names.
Comment 16
Agreed to add a new section:
#.# Security Considerations
An XProc pipeline may attempt to access arbitrary network resources:
steps such as p:load and p:http-request can attempt to read from an
arbitrary URI; steps such as p:store can attempt to write to an
arbitrary location.
In some environments, it may be inappropriate to provide the XProc
pipeline with access to these resources. In a server environment, for
example, it may be impractical to allow pipelines to store data. In
environments where the pipeline cannot be trusted, allowing the
pipeline to access arbitrary resources may be a security risk.
A conformant XProc processor may limit the resources available to any
or all steps in a pipeline. A conformant implementation may raise
dynamic errors, or take any other corrective action, for any security
problems that it detects.
Comment 21
Add a system-property for the language, use that to select from a list
of possibile localized messages
Comment 22
We can add the version attribute later
Comment 23
Should be yellow (consensus achieved)
Comment 25
Covered by proposal for 23
Comment 26
We have serialization controls. We don't deal with non-XML outputs.
Comment 27
Not in V1.
Comment 29
Much discussion of the various options...
<p:input no-input=true no-output=true
Input and output declarations are required on p:pipeline
1. Always require the declarations
2. Add a new 'stdio' attribute, defaults to true, and if true:
a. You get primary input and output declarations, if necessary
b. There must be no declarations of any kind and you get one stdin
and one stdout
3. Add new attributes to allow the author to suppress stdin/stdout
Proposed resolution: You must declare them on p:pipeline; no magic
defaulting of stdin and stdout.
--- Consideration of two of the major MK/XSLT WG comments ---
Comment XX:
Version of xpath -- use anything you want
Some interoperability problem
Pipeline authors SHOULD restrict theselves to expressions that work identically
in all versions of XPath.
Proposal sent to list.
Comment YY:
Version of xslt -- use anything you want
Proposal sent to list.
---
Comment 30
The WG has consensus that parameters are strings
Comment 31
The WG has consensus on what it wants. See Alex's proposed text; issue 74.
Comment 32
Agreed.
Comment 33
We talk about other names
Comment 34
Implementation defined
Comment 35
Happy with Norm's reply.
Should distinguish between the equivalent of http 401 and 404?
In the security consideration section, we'll suggest a specific
dynamic error for "not authorized".
Comment 36
Suggest: XPath Extension Functions
Note that other extension functions are implementation-defined.
Comment 37
"best efforts" at uniqueness. For example, a UUID.
Comment 41
Norm will see if Jim is satisfied
Comment 43
p:try/p:catch does not protect you from static errors, but it does
protect you from dynamic errors. So it does protect you from dynamic
errors detected statically.
So you can't detect it in a try.
We will clarify that dynamic errors that are lexically within a p:try
must not be converted to static errors.
Comment 44
Change to "It is a dynamic error (err:XC0021) if the scheme of the
href attribute is not supported. It is implementation defined which
schemes are supported. Implementations MUST support the "http"
scheme."
Comment 45
Default should be false, but editor pick a name
Comment 46
Editor to consider a clarification.
Comment 47
Delete the paragraph.
Comment 49
This doesn't seem problematic to us. Editor to consider.
Comment 50
Overtaken by events
Comment 52
Yes, it's a dynamic error.
Add a note to the prose that suggests the protocol is very much like
the http protocol.
Yes, we'll rename the elements.
Comment 53
ACTION: Alex to reconsider http-request and the interaction of
content-type, content-encoding, multipart, and the actual use cases
for uploading files.
Comment 54
Skipped for the moment
Comment 55
Fix the typo
Comment 56
Optional step.
<p:declare-step type="p:hash">
<p:input port="source"/>
<p:output port="result"/>
<p:input port="parameters" kind="parameters" primary="false"/>
<p:option name="value" required="true"/>
<p:option name="algorithm" required="true"/>
<p:option name="match" required="true"/>
</p:declare-step>
Parameters are algorithm dependent.
The computed value is used as the replacement where match matches
per p:string-replace
Comment 57
Same as p:hash
Comment 58
Write up in more detail.
Comment 59
If we did this, options require complicated static anlysis to figure
out if there is circularity.
Comment 60
Implementors can provide this, but we're not going to.
Comment 61
No APIs.
Comment 62
ACTION: Henry to explain that our requirements for faithful transcription
of responses is much lower and the resulting simplification is of value
to our users.
Comment 63
Too many namespaces already.
Comment 64
Ok.
Comment 65
Use dtd-validate
Skip the encoding.
Comment 66
No and no, respectively.
Comment 67
No.
Other actions:
ACTION: Alex to look through the library for security considerations.
ACTION: MSM to consider what steps might be considered "core" and which
could be implemented in terms of those core steps.
ACTION: Norm to make sure that we say that the WF constraints in XML 1.0
are checked between steps. Add a new dynamic error to 2.2.
ACTION: Norm check on the status of the system-property function vis-a-vis
XPath vs. XSLT
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | We are the people our parents warned us
http://nwalsh.com/ | about.--Jimmy Buffett
Received on Monday, 12 November 2007 15:23:07 UTC