- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 25 Feb 2015 10:31:12 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87bnkiq7fz.fsf_-_@nwalsh.com>
Resending so that it's easier to find in the archives. I accidentally sent this with the wrong subject the first time. Norman Walsh <ndw@nwalsh.com> writes: > See http://www.w3.org/XML/XProc/2015/02/25-minutes > > [1]W3C > > - DRAFT - > > XML Processing Model WG > > 25 Feb 2015 > > [2]Agenda > > See also: [3]IRC log > > Attendees > > Present > Henry, Loren, Norm, Jim, Murray, Alex > > Regrets > > Chair > Norm > > Scribe > Norm > > Contents > > * [4]Topics > > 1. [5]Accept this agenda? > 2. [6]Accept minutes from the previous meeting? > 3. [7]Next meeting > 4. [8]Review of open action items > 5. [9]Report from XML Prague > 6. [10]Face-to-face in June > 7. [11]Default error ports, issue 136 > 8. [12]Generalized XML Validation step, issue 135 > 9. [13]Clarify the distinction between p:input declarations and > connecctions even better, issue 147 > 10. [14]Any other business? > > * [15]Summary of Action Items > > -------------------------------------------------------------------------- > > Accept this agenda? > > -> [16]http://www.w3.org/XML/XProc/2015/02/25-agenda > > Accepted. > > Accept minutes from the previous meeting? > > -> [17]http://www.w3.org/XML/XProc/2015/03/04-minutes > > Accepted. > > Next meeting > > Proposed: 04 March 2014 does anyone have to give regrets? > > Jim gives likely regrets for 4 Mar > > Review of open action items > > Norm: Any progress? > > 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 > [18]http://www.w3.org/2015/02/25-xproc-minutes.html#action01] > > 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 - > [19]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 > [20]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? > > Adjourned. > > Summary of Action Items > > [NEW] ACTION: A-256-02 Norm to attempt to spec out a generalized > p:xml-validation step. [recorded in > [21]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 > [22]http://www.w3.org/2015/02/25-xproc-minutes.html#action01] > > [End of minutes] > > -------------------------------------------------------------------------- > > Minutes formatted by David Booth's [23]scribe.perl version 1.140 ([24]CVS > log) > $Date: 2015-02-25 16:29:13 $ > > References > > 1. http://www.w3.org/ > 2. http://www.w3.org/XML/XProc/2015/02/25-agenda > 3. http://www.w3.org/2015/02/25-xproc-irc > 4. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#agenda > 5. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item01 > 6. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item02 > 7. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item03 > 8. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item04 > 9. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item05 > 10. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item06 > 11. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item07 > 12. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item08 > 13. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item09 > 14. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#item10 > 15. http://www.w3.org/XML/XProc/2015/02/25-minutes.html#ActionSummary > 16. http://www.w3.org/XML/XProc/2015/02/25-agenda > 17. http://www.w3.org/XML/XProc/2015/03/04-minutes > 18. http://www.w3.org/2015/02/25-xproc-minutes.html#action01] > 19. http://www.oxygenxml.com/doc/ug-author/index.html#concepts/oxygen-processing-instruction.html > 20. http://www.w3.org/2015/02/25-xproc-minutes.html#action02] > 21. http://www.w3.org/2015/02/25-xproc-minutes.html#action02 > 22. http://www.w3.org/2015/02/25-xproc-minutes.html#action01 > 23. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > 24. http://dev.w3.org/cvsweb/2002/scribe/ Be seeing you, norm -- Norman Walsh Lead Engineer MarkLogic Corporation Phone: +1 512 761 6676 www.marklogic.com
Received on Wednesday, 25 February 2015 16:32:14 UTC