See also: IRC log
-> http://www.w3.org/XML/XProc/2008/05/08-agenda
Henry suggests setting an end date for new features, added under Any Other Business
-> 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.
Norm gives likely regrets. Henry to chair.
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]
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]
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]
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]
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.
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.
None heard.
Adjourned.