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

XProc Minutes 8 May 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 08 May 2008 14:41:37 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m28wykiqou.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/05/08-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 111, 08 May 2008


   See also: IRC log[3]


           Norm, Mohamed, Paul, Alex, Rui, Vojtech, Richard, Henry, Andrew





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting 15 May 2008
         4. What PSVI properties survive going through which steps?
         5. Support for other media types in p:unescape-markup
         6. Should p:library allow p:pipeline?
         7. Deadline for new features?
         8. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/05/08-agenda

   Henry suggests setting an end date for new features, added under Any Other

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/05/01-minutes

   Norm observes that he's made the changes proposed and checked in a new


   Mohamed: The example in the minutes is not XProc.

   Norm: Heh.

   Norm to amend the minutes with the corrected example.


  Next meeting 15 May 2008

   Norm gives likely regrets. Henry to chair.

  What PSVI properties survive going through which steps?

   Norm attempts to summarize.

   -> http://www.w3.org/mid/f5b63tozyj5.fsf@hildegard.inf.ed.ac.uk

   Henry: I think we need to get some experience in this area, we need to not
   violate the principle of least surprise but at the same time not constrain
   things too far.

   Alex: The XSLT/XQuery story is draconian: you lose if you copy.

   Henry: Processors are always able to say that they throw out everything.
   ... But viewporting, by definition, doesn't change the validity properties
   of the portions that are viewported. We don't want to rule that out.
   ... There's one way that's false, actually, because the IDREF constraints
   are checked at document level.
   ... In the input to a viewport, all the properties are correct except
   possibly the properties on the root element itself.

   Richard: The suggestion that implementations can delete but MUST ensure
   accuracy blows away interoperability, doesn't it?

   Henry: Yes, but it's not clear that that's a criticism. We'll find out.
   ... Even if all that you're guaranteed is that until you've gone through a
   step PSVI properties are there and you can put validate followed by XSLT2
   and know you're going to win will be valuable.

   Norm: The interoperability story is what worries me. There's at tradeoff
   between consistency and interesting implementation, I guess.

   Alex: If I have a step that produces an infoset from whole cloth and it
   produces PSVI properties, it could assign those things any random value
   that you wanted and they could not be true.
   ... Is that OK?

   Henry: It seems to me that it is. I'd like to be able to write a step that
   takes a PSVI and fixes some of the errors in the Schema 1.0 PSVI by
   turning them into infoset properties.

   Richard: If you take Alex and Henry's position together, this would cause
   the next step to immediately discard the incorrect properties.
   ... So we really want to say that any properties that /were/ correct MUST
   still be correct.

   Henry: Yes.
   ... if you say you support the PSVI, that means that the pipes carry the
   PSVI. So if the output has PVSI properties, those properties are there on
   the input of the next step.
   ... Mohamed's response takes it one step further. If a processor says that
   it supports the PSVI, and it supports XPath 2.0, then you hsould be able
   to use type-aware XPaths in any XPath that is evaluated against the input.
   ... Maybe that's as far as we can go.
   ... The identity step won't preserve PSVI properties, but maybe that won't
   matter in practice.
   ... But what about viewport?
   ... What about the builtin compound steps?
   ... Does it follow from all of this that you wrap part of a pipeline in a
   group, you lose the PSVI? I sure hope not.
   ... There's no conceptual difficulty in saying that for for-each, choose,
   and group, the properties should be copied.
   ... Viewport is arguable, but I'd like to do it there too. And in try.

   Norm: Yeah. Not preserving the PSVI coming out of a p:choose would make
   PSVI support pretty pointless.

   Henry: So p:viewport is the one that seems arguable.

   Norm: So viewport produces a weird mix of PSVI and not PSVI?

   Henry: No. The first step in the viewport subpipeline sees the PSVI
   properties of its input.
   ... The output is clean, no PSVI.
   ... The next step up would be to say that if the last step in the viewport
   produces PSVI then the "islands" get PSVI proprties too.

   Norm wonders if we can finish this on the call or if we should go back to
   email for a propsoal.

   <scribe> ACTION: Henry to draft a proposal for how PSVI support should be
   exposed across steps in the pipeline. [recorded in

  Support for other media types in p:unescape-markup

   Vojtech: The first question about the content type seems ok, but then I
   had more questions about what should happen if the unescaping fails
   because the content is not WF XML or whether the XML decl should be

   Norm: I think the step fails if the escaped markup isn't WF.

   Vojtech: The way the unescape markup step works, if the root element has a
   default namespace, then the unescaped markup inherits it.
   ... But what about if the markup has a default namespace declaration?

   Norm: Yes, I think that should be clear.

   Alex: There's nothing funky here like DOM where there are default
   namespaces and such. We just parse and take what the parser gives us.

   <scribe> ACTION: Alex to review unescape-markup and see if any
   clarification seems to be needed. [recorded in

   Alex: As far as text/xml goes, for text embedded in another document, some
   folks do use text/xml.

   Norm: I don't there's any support for that.
   ... I guess if there's an escaped XML declaration, you have to just throw
   it out.

   Richard: The obvious thing you have to do is ignore the encoding

   Alex: We take the sequence of characters, if there's an XML decl in there,
   the parser will see it and do whatever it does. You the receiver will get
   it and not have anywhere to put it.

   Some discussion of the encoding issues.

   Henry: I'm still struggling with what it means to ignore the XML decl. One
   way is to say <?xml is stripped out of the decoded text before parsing.
   The other is to parse it and say that the properties it would set are
   ignored in the resulting infoset.

   <MoZ> ht, that's not that simple because of <?xml-stylesheet ?>

   <Norm> MoZ, then "<?xml " :-)

   <MoZ> :) you win

   <scribe> ACTION: Richard to attempt to clarify the prose of the
   unescape-markup with respect to the XML Declaration, document types, XML
   version, etc. [recorded in

   Mohamed: I think that what troubles me about the XML declaration is that
   escape-markup needs to clarify the meaning of the omit-xml-declaration.

   Alex: No, that's a standard serialization option.

   Mohamed: But it's escaping, not serializing.

   Richard: Even XSLT 1.0 has an omit-xml-declaration option.
   ... I think 'unescape' would be better thought of as parse-from-text and
   escape as serialize-to-text.

   More discussion of how serialization and escaping interact.

   Vojtech: My question about the XML declaration was much simpler. I just
   wondered if it should be generated by default or not. It seems to me that
   the escape-markup step should probably not generate it by default.

   Richard: Yes, the only useful thing you can put in it is standalone.

   Alex: We don't say what the default for generating the declaration is,
   that's a problem.

   <scribe> ACTION: Alex to say what the default value for
   omit-xml-declaration is. [recorded in

  Should p:library allow p:pipeline?

   Norm: Why don't we allow p:pipeline in p:library?

   Alex: Now that they're equivalent, I don't see why not.

   Proposal: Allow p:pipeline in library?


  Deadline for new features?

   Henry: I propose today.

   Alex: The big question I have is, what else on our agenda has to be

   Henry: What I meant is, if it's not on our agenda at COB CA time today, it
   has to be a bug or it's in v2.

   Norm: Any objections?


  Any other business?

   None heard.


Summary of Action Items

   [NEW] ACTION: Alex to review unescape-markup and see if any clarification
   seems to be needed. [recorded in
   [NEW] ACTION: Alex to say what the default value for omit-xml-declaration
   is. [recorded in
   [NEW] ACTION: Henry to draft a proposal for how PSVI support should be
   exposed across steps in the pipeline. [recorded in
   [NEW] ACTION: Richard to attempt to clarify the prose of the
   unescape-markup with respect to the XML Declaration, document types, XML
   version, etc. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/05/08-agenda
   [3] http://www.w3.org/2008/05/08-xproc-irc
   [7] http://www.w3.org/2008/05/08-xproc-minutes.html#action01
   [8] http://www.w3.org/2008/05/08-xproc-minutes.html#action02
   [9] http://www.w3.org/2008/05/08-xproc-minutes.html#action03
   [10] http://www.w3.org/2008/05/08-xproc-minutes.html#action04
   [11] http://www.w3.org/2008/05/08-xproc-minutes.html#action02
   [12] http://www.w3.org/2008/05/08-xproc-minutes.html#action04
   [13] http://www.w3.org/2008/05/08-xproc-minutes.html#action01
   [14] http://www.w3.org/2008/05/08-xproc-minutes.html#action03
   [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [16] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[15] version 1.133 (CVS
    $Date: 2008/05/08 18:40:54 $

Received on Thursday, 8 May 2008 18:42:12 UTC

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