W3C

- DRAFT -

XML Processing Model WG

Meeting 263, 28 Jan 2015

See also: IRC log

Attendees

Present
Jim, Norm, Alex, Henry
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2015/01/07-minutes

Accepted.

Next meeting

4 Feb 2015, any regrets?

No regrets heard

Review of open action items

Jim reports completion of A-260-01

-> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2015Jan/0007.html

And A-260-02

-> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2015Jan/0009.html

And A-260-03

-> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2015Jan/0008.html

Jim: The open question is, for the use cases, I've culled some from previos versions.
... And written my own.
... I've also asked in public about the non-XML flows.

Jim: Should we put these in the requirements document?

Norm: If the WG agrees that they're use cases we want to take on for 2.0, then I think we can add them to the Use Cases and Requirements document.

Jim: We put the use cases in and we traced them back to the spec; we also traced requirements back.
... Do we want to do that now? Not sure.
... I'll send them along be email and we can start with those and see what we want to do.

Norm: Sounds good to me.
... You also sent mail about a p:sign step.

Jim: Yes, I saw that we had discussed that previously.

Alex: I think signatures in general, XML Signatures being a specific case, would be worth exploring.
... There's lots of code out there and it's a good thing. It seems possibly like two different steps.

Some discussion of exec and eval

Jim: I'll take a stab at p:sign for the XML case and the non-XML case.

<Zakim> ht, you wanted to mention use of metadata for this

Henry: It occurs to me that as is the case with some other aspects of what you can consider ultimate outcome, some steps may be properly implemented as actually only adding metadata.
... It's perfectly coherent to say that I have an XML Signature step that only bites at the edge of the pipeline.
... It doesn't have to be the case that adding an XML Signature step means that thereafter what's flowing through the pipeline is encrypted.
... Also, wrt the observation about implementability, I think we have an opportunity to do a good deed and enlist help in doing it.
... I think the fact that XML Encryption is not widely used is a real flaw in the XML ecology and adding easy, straightfoward support in XProc v.next would be a huge encouragement to people to use it.
... So I think if we asked the community that does know how it works to help, they'd help because it's a win-win.

ACTION A-26x-01: Norm to ask Frederick Hirsch for help with the encryption implementation parts.

Henry: And finally, wrt use cases, I implemented a bunch of support for interactions with amazon web services with the Markup Pipeline for which the "B-case" that Alex mentioned was front-and-center.
... Take this 256 bit key as represented in hex and this string and encrypt it so that I can then send it to Amazon web services.

Alex: I think that's just signed for Amazon

Henry: Yes, that might be the case.

Alex: Making that kind of API easier to use would be a very good thing.

Henry: I'm pretty sure I used p:exec for the signature, but I'll drag out the architecture to look at.

Alex: I'll take an action to collection some data too.

Norm: I think we're drifting towards "we need to make OAuth easy from pipelines."

ACTION A-26x-02: Alex to consider the requirements for making it easy for pipelines to talk to web APIst that use these styles of encryption.

Jim: About the edges of the pipeline, are you thinking of a pipeline that just adds metadata to the document?

Henry: Yes and no. What I was thinking of was a pipeline that has a whole bunch of stuff that constructs a document. At some point it wants to specify that some portion of the document should be signed.
... It should be able to do that at the point where that part of the document is in focus. This ought to be able to be used as a subpipeline for example where the whole document isn't in view.
... Suppose it took an XPath and a bunch of args, and said at this point in the pipeline, so the element identified by that XPath should be encrypted.
... Nothing happens except some metadata gets added to document so that *when it's output from the pipeline* the encryption will be performed.
... It amounts to instructions to the output step that go in the metadata. This is useful for other things, like setting the encoding for the document.

Alex: So I have a bunch of questions that come from that: is this how the pipeline is deployed or effected by the information flowing through it.
... It could be a binding outside the pipeline or it could be something the serializer actually does.

Henry: I'm thinking of the latter.

Jim: I don't think we need to go deeper today, I just wanted to understand.

Any other business?

Jim: Where is TPAC? Japan?

Norm: Yes, Japan. I'm hoping to go, but it's unclear.

Alex: I'd like to go, I have a colleague there. I don't know if that's going to be possible.

Jim: If we know we're going, we could start trying to get some interest up in that part of the world.

<ht> I think that would be a great idea

Some discussion of a f2f in Edinburgh in June. Still planning.

Adjourned.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/01/28 15:45:38 $