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

XProc Minutes for Technical Plenary f2f, 8/9 Nov 2007

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 


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
       - 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 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


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"

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"/>

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


Comment 65

Use dtd-validate

Skip the encoding.

Comment 66

No and no, respectively.

Comment 67


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,

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC