Vojtech: My question was about
encodings in general, not that specific one.

Norm: I heard some agreement that
we preserve the values.

Proposal: The charset value (and
other parameters) are preserved.

Accepted.

155/158 Appendix G.

Resolved, see above.

159 p:choose/p:xpath question

Vojtech: What happens if you
specify an xpath context in p:when but you don't specify a
binding?
... In our implementation, the p:when is using the default
readable port, not the binding from p:xpath-context from
p:choose.

Norm: I think this is an edge
case that we didn't think of, so we just need to say what the
answer is.
... Why did we allow the binding inside xpath-context to be
optional?

Vojtech: I think we might have
done it to preserve the default.

Alex: So this one uses the
default context?

Norm: I think there are two
possible interpretations, an empty p:xpath-context either goes
back to the default readable port of the p:choose or it goes
back to the default on p:choose.
... Or we make it illegal by requiring a binding inside
p:xpath-context.

Vojtech: Right now the spec says
it works just like p:input, so it would get connected to the
default readable port.

Norm: Making an empty
xpath-context go back to the choose would be redundant.
... So I think that boils down to two reasonable
intepretations: the default readable port or we make it an
error.
... For the 1 in 999,000 case when someone might use this, I
guess that would be ok.

Mohamed: I think it's a bad idea,
when a user uses xpath-context in the choose, then I think we
should make the user be explicit in any p:when where they want
a different binding.
... I think we should forbid having an empty
p:xpath-context.

Vojtech: I think I agree with
Mohamed on this one.

Norm: Ok by me.

Proposal: Make it an error to
leave the p:xpath-context empty.

Accepted.

Norm: I'll change the content
model so that it's required, we don't need a new error
code.

160 Accomodation for JSON

Norm: The JSON RFC doesn't define
an XML encoding, it just defines JSON

Alex: The c:query step is for
XQuery, not random queries.

Vojtech: Perhaps he meant that if
the content-type on p:data was applicatin/json then it would be
turned into XML.

Mohamed: I don't think the
purpose of this spec is to convert all tree-like structures
into XML.

Henry: I think this is an area
where it's perfectly reasonable for implementors to compete.
When we were doing the markup pipeline, it ended up being the
case that it was appropriate to add a command line switch to
upconvert STDIN from some format (like SGML) to XML.

Norm: Yes, and I think, I'd have
to go back and read carefully, that an impl could recognize
application/json and turn it into XML.
... Nope, I was wrong.

Alex: There's nothing in this
message that seems to imply we're supposed to translate JSON
into XML. We've already got ways to represent JSON in a
pipeline, using c:data.

Some discussion.

Proposal: Reply that you already
can include JSON as text using c:data. If you want conversion
to XML, you'd need an extension step for that.

Accepted.

Some additional discussion of Henry's use
case.

161 Concerns about forwards-compatible
mode

Some discussion. General agreement that making
the error dynamic rather than static would be very painful for
implementors.

Alex: Changing the definition of
a fundamental step is a bad idea

Norm: I think the rules we have
are fine, the consequence of the rules is that for some
changes, we'll introduce a new namespace or change the step
name.

Alex: So that just means he has
to rearrange the choose, right?

Norm: Right.

Alex: So the end result would be
just a slightly different pipeline.

Proposal: Reject making the error
dynamic, point out that the constraints are on future versions
of steps with the same names, not future functionality.

Accepted.

Vojtech: I think there are two
more questions. What happens if the schema changes so that some
elements can contain new elements that weren't supported in
V1.

Norm: Oh, so we add a p:xyz child
of steps.

Vojtech: Not just steps, but also
in p:serialization, for example.
... or in p:document we add a new child.

Norm: I guess we could say that
those are ignored. I have some reservations, but I can't
articulate them.

Vojtech: I can imagine cases
where this could cause problems. What if we wanted to add a new
kind of instruction like p:choose or p:try. If you ignore it
then the pipeline might not make any sense anymore.

Norm: Right so if we add
p:map-reduce ignoring it would be all you could do but it
wouldn't be the right thing.

Mohamed: I think it has to
fail.

Norm: If we add new language
elements then you can't write backwards compatible pipelines
that use them.

Vojtech: If you introduce a new
builtin step then you could wrap it in a choose and use step
available.
... No, that won't work because you have to know the
signature.

Mohamed: The problem we have is
that we have to compute a new dependency graph. Adding new
builtin constructs just makes it not backwards compatible.

s/compabiel/compatible/

scribe: I don't find it too
restrictive, because when we provide a new instruction perhaps
we can provide a wrapper step for it.

Proposal: No, we're not going to
ignore unknown elements.

Accepted.

Norm: And the last one is covered
by the fact taht you're not allowed to declare steps in the p:
namespace unless the URI begins with the right prefix.