See also: IRC log
-> http://www.w3.org/XML/XProc/2008/11/13-agenda
Accepted
-> http://www.w3.org/XML/XProc/2008/10/tpac-minutes
Accepted.
Vojtech gives regrets.
-> http://www.w3.org/XML/XProc/2008/08/lastcall/comments.html
Proposal: close with no action
Vojtech: I agree, but I think
some people might find it strange.
... But a new step would amount to the same amount of code, so
it's fine.
Accepted.
Norm thinks that a custom method on p:store is probably sufficient, binary data isn't the focus of our language.
Mohamed: Norm used content-type, but we don't have that attribute
Norm: I meant "media-type" I guess.
Mohamed: So it wouldn't be interoperable. So it'd be <p:store method="foo:binary"> ...
Norm: yes.
Alex: Are we putting something like this in the document.
Norm: I was proposing to add a note.
Mohamed: A parallel question: for
p:data and c:data it's content-type, that's probably why there
was confusion.
... Where does this difference come from?
Alex: HTTP uses a content-type header and all the internet-speak uses media-type. The serialization parameter is called media-type.
Mohamed: The value is the same?
Alex: Yes, the value of the
media-type header is a content-type.
... We could decide to be consistent and use media-type
throughout and be inconsistent with the HTTP RFC.
Mohamed: I thought the difference might be that content-type also has a charset value.
Alex: That's a good point. Maybe
that's why it's called content-type vs. media-type, I'm not
sure.
... The names should be separate because the content-type can
have parameters.
Norm: Yes, we have two different names, but I think we're going to leave them the way they are.
Mohamed: I just wanted to make sure that we don't mix the two.
Proposal: No change to the spec, but add a note about using an extension to p:store to save binary data.
Accepted.
Norm summarizes Vojtech's mail
Norm: I don't feel strongly about it, but it does seem a little inconsistent.
Alex: I like the apply-to change, but I'd use the values "elements" and "attributes" without "-only"
Proposal: Rename element-only to apply-to as suggested.
Accepted.
Norm: Anyone remember why we made path optional?
Henry: No, I don't, and it doesn't seem terribly plausible. I think we should just make it required.
Alex: How do you get the current
directory of the pipeline or the source document?
... Maybe this meant the current directory the document is in
or the current directory of the application?
Henry: You can use the base-uri function. It might be reasonable to say that it peels back to the last forward-slash in the base URI.
Vojtech observes that a relative directory is resolved against the step, so it works out to the same thing as specifying ""
Henry: I do think we need some words that say that everything after the last slash is discarded.
<alexmilowski> ./
Richard: I don't think we need to do that, we could just say that it's the empty string by default.
Norm: Can't we just make it required?
Richard: We can say that if it's not specified it's "."
Mohamed: I think it makes more sense to make it required.
Vojtech: There was a similar problem with p:store, which we fixed by making href on p:store required.
Proposal: Make it required.
Mohamed: Is it possible to add a note to say that use "." for the current directory.
Norm: Sure, we can do that.
Richard: It isn't the current directory, it's the directory you get by resolving "." against the base URI.
Henry: We needed to add that to the Markup Technologies pipeline, but not here, not today.
Richard: Since "." doesn't give the CWD, I think it's much less common.
Norm: So the proposal is to make it required and not add the note.
Accepted.
Norm summarizes
Some discussion of whether or not this is really a problem and if it would in fact be a feature for this case to work.
Henry: This is similar to the
problem of having two different schemas for the same namespace
in the same context.
... I think it's too late to figure out how to cope with this
in this version of this language.
Vojtech: I agree
Henry: Somewhat regretfully, we have to say this isn't going to be properly addressed until we get to V2.0
Norm: Vojtech's point is a good one, we could make this work, but not in V1.0
Mohamed: I'm still confused. If you have a V1 processor processing the pipeline so it'll start with a V1 library.
Norm: It just seems to me that asking the implementation to change it's idea of what the pipeline library is half way through invites interoperability issues and mayhem.
Henry: The isn't it better to say that a processor may through an error if it encounters an import of a new version "too late" where "too late" is implementation defined.
Vojtech: Why would we have to go back and change the declaration? The import statement is always in scope for a library or compound step.
Norm: The XProc library is
special, it's allowed to include redeclarations.
... Maybe the best we can do is what Henry suggested.
Alex: So there are two issues, the ability to throw an exception, and if I load this, then what happens with optional options.
Norm: I think the question of optional options are fully covered by the spec.
Henry: The only question we
didn't answer was what we should do in the nested case.
... I think the simplest thing to do is just say that
processors are allowed to reject this.
... Asking for complete consistency about all possilbe
scenarios seems premature. We've got a consistent story that we
know we want to work: if you import the library up front.
... Beyond that, I think we should just say that processors can
reject it if they want.
Mohamed: I'm ok with that.
Vojtech: I'm ok too.
Proposal: Processors are allowed to reject the import of a V.next library if it occurs "too late", where too late is implementation defined.
Accepted.
Norm will produce a CR draft. Henry will arrange a transition call.
Adjourned