- 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
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 111, 08 May 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Mohamed, Paul, Alex, Rui, Vojtech, Richard, Henry, Andrew
Regrets
Chair
Norm
Scribe
Norm
Contents
* 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
Business
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
draft.
Accepted.
Mohamed: The example in the minutes is not XProc.
Norm: Heh.
Norm to amend the minutes with the corrected example.
Accepted.
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
http://www.w3.org/2008/05/08-xproc-minutes.html#action01[7]]
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
present.
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
http://www.w3.org/2008/05/08-xproc-minutes.html#action02[8]]
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
declaration.
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
http://www.w3.org/2008/05/08-xproc-minutes.html#action03[9]]
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
http://www.w3.org/2008/05/08-xproc-minutes.html#action04[10]]
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?
Accepted.
Deadline for new features?
Henry: I propose today.
Alex: The big question I have is, what else on our agenda has to be
addressed?
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?
Accepted.
Any other business?
None heard.
Adjourned.
Summary of Action Items
[NEW] ACTION: Alex to review unescape-markup and see if any clarification
seems to be needed. [recorded in
http://www.w3.org/2008/05/08-xproc-minutes.html#action02[11]]
[NEW] ACTION: Alex to say what the default value for omit-xml-declaration
is. [recorded in
http://www.w3.org/2008/05/08-xproc-minutes.html#action04[12]]
[NEW] ACTION: Henry to draft a proposal for how PSVI support should be
exposed across steps in the pipeline. [recorded in
http://www.w3.org/2008/05/08-xproc-minutes.html#action01[13]]
[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
http://www.w3.org/2008/05/08-xproc-minutes.html#action03[14]]
[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
log[16])
$Date: 2008/05/08 18:40:54 $
Received on Thursday, 8 May 2008 18:42:12 UTC