See also: IRC log
Last week's minutes: http://www.w3.org/XML/XProc/2008/06/05-minutes.html
Accepted.
Next meeting: 19 June 2008, regrets from Andrew only ones known as yet
MZ: Features suggested by
Alessandro's suggestions based on Haskell:
... p:is-empty is covered by limit attr on p:count
... p:pack has been added
... split a sequence up until the first failure to match some pattern still needs a way
to happen
http://www.w3.org/TR/xproc/#c.split-sequence
HT: Sounds straightforward
... anyone see any difficulties?
MZ: This gives us functionality for dealing with sequences which it's difficult, if not impossible, to get any other way
HT: Better name than
'stop-test-after-first-false' ?
... We get the initial subsequence which matches
AM: I get it
HT: How about 'initial-only'
AM: It's going to be opaque, people will have to look it up to understand it
RESOLUTION: Add an 'initial-only' attribute to p:split-sequence, a boolean
<scribe> ACTION: Alex Milowski to add an 'initial-only' attribute to p:split-sequence, a boolean [recorded in http://www.w3.org/XML/XProc/2008/06/12-minutes.html#action01]
AM: The origin of the impl-defined for the defaults for unspec'd serialization options comes from the QT Serialization spec.
MZ: That's not what I was concerned about, rather that I read the spec. in 5.6 as allowing other attributes which are not specified in the spec.
HT: Oops, this section needs to be cross-referenced from 7.3
AM, MZ: Discuss what 'unspecified' means here
HT: I think that the intent was that 'unspecified' refers to _options_ which are missing for a particular step
AM: Right
MZ: Yes
HT: But, alas, the Serialization spec.
does not say that defaults are impl-defined
... Propose to delete the "default value" sentence from 5.6
RESOLUTION: delete the "default value" sentence from 5.6
HT: Propose to amend the reference to 7.3 in 5.6 to read as follows:
The semantics and defaulting behaviour of the attributes on a p:serialization are as described for the corresponding options Section 7.3, “Serialization Options”.
RESOLUTION: Amend the reference to 7.3 in 5.6 to read as follows: "The semantics and defaulting behaviour of the attributes on a p:serialization are as described for the corresponding options in Section 7.3, “Serialization Options”."
<scribe> ACTION: Alex Milowski to draft a Note to add to 7.3 explaining that we don't give simple defaults, behaviour wrt missing options is complex and you have to read [Serialization] to find out. [recorded in http://www.w3.org/XML/XProc/2008/06/12-minutes.html#action02]
<scribe> ACTION: Alex Milowski to add an error to 7.3 to cover all other parameter-related Serialization errors [recorded in http://www.w3.org/XML/XProc/2008/06/12-minutes.html#action03]
MZ: My email also proposes adding support for c14n to serialisation
HT: I am opposed, it's a new feature, and it can be easily fitted into the existing spec. as an impl-defined serialization method
AM: I'm opposed also, we should wait for Serialization spec. to provide for this, so we don't find ourselves isolated when they do
MZ: So, do you mean there would have to be two new methods, x:c14n-with-comments and x:c14n-without-comments
HT: No, I think you would have new options to go with impl-defined x:c14n method
AM: What happens when Serialization does add support for c14n -- do those attributes/options move from prefixed to unprefixed?
HT: MSM would say "we should say 'Serialization or its successors'"
AM: The problem is that it's not hard
to allow for new serialization options, when there's a new
Serialization spec., but adding attributes in no namespace to
p:serialization is not allowed
... Maybe we should provide for this ahead of time, with a specific
namespace.
HT: We're out of time, AM please start an email thread on your idea, we'll pick it up next week.
HT: Adjourned