- 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