W3C

- DRAFT -

XML Processing Model WG

25 Feb 2015

Agenda

See also: IRC log

Attendees

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

Contents


Date: 25 February 2015

<scribe> Meeting: 265

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Accept this agenda?

-> http://www.w3.org/XML/XProc/2015/02/25-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2015/03/04-minutes

Accepted.

Next meeting

Proposed: 04 March 2014 does anyone have to give regrets?

None heard.

Review of open action items

Norm: Any progress?

Jim gives regrets for 4 Mar

Norm: Nope.

Report from XML Prague

Norm: Pre-conference session, dinner, and conference session. Good feedback all around.

Alex: It's nice to see people who are using XProc. There's definitely random folks using it that we don't know about. That's kind of cool.

Jim: I had a lot of individual conversations and I think there are quite a few people tracking the 2.0 effort. Anecdotally, I think people are interested.
... Everyone was very positive about where 2.0 is going which made me happy. The other thing that struck me is that there seems to be a general emergence of pipelines as a problem solving strategy.
... Not everyone is using XProc, but they are interested in pipelines. I don't think they were turned off by it but for one reason or another it didn't fit.

Loren: I think XProc needs a GUI editor.

Jim: I'm sure this WG has talked about it a lot. Visualizing is one thing. Programming with a visual editor is another thing.
... I have a pretty negative attitude personally about visual programming.
... When I was looking at XProcDoc, I was thinking it might be nice to have a visual output from that.
... Overview diagrams are nice and they demo well.

Norm: My v2 engine includes an "output the graph" function.

Loren: PTC has a very good graphical workflow editor.

Face-to-face in June

Norm mumbles about dates.

Norm: I expect to be in London for XML London (5-7 June).

Jim: That might work better for me.

Henry: I might make it to XML London too, if we had a space, we could conceivable have the meeting in London.

Jim: I have a place in London we can use.

Norm: I might be able to get MarkLogic to host us.

Henry: I'm transitioning through London on 4 June, so I could conceivable stay.

Norm: So something like 8-10 June.

Henry: I'm happy to host in Edinburgh, but I don't insist on it.

Norm: I don't object to moving to Edinburgh.

Jim: It doesn't matter to me.

Proposed: XProc will meet f2f in Edinburgh, 10-12 June 2015.

Norm: Henry, will you investigate scheduling?

Henry: Doing it now...
... We can have the room we've met in before.

Default error ports, issue 136

Jim: I think there's some email about this. The idea is that every port would have a default error port.
... The reason that I put this on there is that I didn't see any absolute objections to it.
... The idea is that every step would have an error port that would emit information.

Norm: For xsl:message, for schema validation errors, etc., yes?

Jim: Yes.
... I do think at the moment that we real problems debugging pipelines.

Norm: The only thing I recall is that we either need to define the error format or we are describing a non-interoperable feature.
... But I have encountered pipelines where users wanted xsl:messages or validation errors.

Jim: I haven't really thought it through, but I wanted to take the temperature of the group.

Alex: I'm a fan of being able to trap errors and do intelligent things with them. People writing enterprise software would really like it. But we have to attempt to explore interoperability.

Henry: Works for me.

<scribe> ACTION: A-265-01 Jim to attempt to describe a minimally interoperable error format for a standard error port. [recorded in http://www.w3.org/2015/02/25-xproc-minutes.html#action01]

<jfuller> fyi- I am on mute

Generalized XML Validation step, issue 135

ht, I muted you. Sorry

Norm: This is a proposal for a step that uses the xml-model PI and does a variety of different validation technologies
... There is variation in the options and such, but parameters (in V2) would make that easier.

Jim: I wonder if what is proposed couldn't be done with just an NVDL step orchestrating things.

<ht> I think it's worth trying, at least as far as CR, since we really need to hear if it can be made to work

Norm: I don't know if NVDL has a "dispatch based on model PI" or not.

Jim: Probably doesn't.
... It's a question of what we build in and what comes as extensions.

<ht> I would go the other way, wrt what Norm just said: Add a step which has arguments which mimic the model PI

<ht> So that people don't have to piss around faking up a model PI and adding it

<jfuller> ex - Oxygen has <?oxygen NVDLSchema="xhtml-xforms.nvdl"?>

<ht> I'm not saying we shouldn't have the step that interprets the PI

Norm: I'm not a huge fan of the model PI but I'm not sure where that's going.

Henry: All I meant was, it seems to me that a. having a step that interprets the model PI and does validation seems sensible to me; not sure if it can be made to work but htat's what CR is for.
... In addition, I would like to be able to say, given a document that I'd like to validate that there isn't a specific step for. I'd have to add a model PI and then pass it to the step.

<Loren> It looks like I am losing my conference room. I am going to have to drop off the call.

Henry: It ought to be possible to have a builtin step to say that in the absence of the model PI, there are a bunch of parameters that give you the model PI that you wish you had put there.

<jfuller> guessing this is the use case on discussion - http://www.oxygenxml.com/doc/ug-author/index.html#concepts/oxygen-processing-instruction.html

Jim: Are we talking just xml-model.

<ht> I thought in the introduction you had said that the need for this was driven in part by the fact that the space of validators larger than the (likely) space of validation steps

<ht> OK, what you _just_ said about no PI is incompatible with what I suggests

Norm: That might be true, but it's not exactly what I meant.
... No one is saying this is a bad idea, so we should consider trying to spec it out.

<scribe> ACTION: A-256-02 Norm to attempt to spec out a generalized p:xml-validation step. [recorded in http://www.w3.org/2015/02/25-xproc-minutes.html#action02]

Clarify the distinction between p:input declarations and connecctions even better, issue 147

Norm: I thought the agenda needed something a little more open ended :-)

Norm waffles on a bit about the fact that we have p:input doing distinct but subtly different jobs.

Jim: I think at this stage in the game, I don't want to change things. If we solved this problem with a bit more words, that would be good enough.

Norm: I'm happy to file this as an editorial, we need to explain this better problem, rather than adopting a technical language change.

No one suggests otherwise.

Any other business?

<jfuller> Thanks Alex !

Adjourned.

Summary of Action Items

[NEW] ACTION: A-256-02 Norm to attempt to spec out a generalized p:xml-validation step. [recorded in http://www.w3.org/2015/02/25-xproc-minutes.html#action02]
[NEW] ACTION: A-265-01 Jim to attempt to describe a minimally interoperable error format for a standard error port. [recorded in http://www.w3.org/2015/02/25-xproc-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-02-25 15:47:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/includes a/includes an/
Found Scribe: Norm
Inferring ScribeNick: Norm
Found ScribeNick: Norm
Present: Henry Loren Norm Jim Murray Alex
Agenda: http://www.w3.org/XML/XProc/2015/02/25-agenda
Found Date: 25 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/25-xproc-minutes.html
People with action items: a-256-02 a-265-01 jim norm

[End of scribe.perl diagnostic output]