W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2013

XProc Minutes 17 January 2013

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 23 Jan 2013 07:05:07 -0600
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2wqv46oe4.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2013/01/17-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 224, 17 Jan 2013

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Mohamed, Jim, Alex, Vojtech, Henry

   Regrets
           None

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: 24 Jan 2013
         4. [8]Change meeting time?
         5. [9]Review of open action items
         6. [10]Review progress on use cases/requirements
         7. [11]Review of proposal to simplify parameters
         8. [12]Support for document metadata?
         9. [13]Any other business?

     * [14]Summary of Action Items

   --------------------------------------------------------------------------

  Accept this agenda?

   -> [15]http://www.w3.org/XML/XProc/2013/01/17-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> [16]http://www.w3.org/XML/XProc/2012/11/01-minutes

   Accepted.

  Next meeting: 24 Jan 2013

   No regrets

  Change meeting time?

   Jim: I'm finding Thursday challenging.

   Norm: Time of day is to suit west coast USA and Europe.
   ... I don't like Monday's for meetings. I could do Tue, Wed, or,
   reluctantly, Friday.

   Jim: Maybe Cornelia would be able to make it if we moved the meeting time?

   Alex: Henry has a complicated schedule too.

   <scribe> ACTION: Norm to send email polling for a different/better meeting
   time. [recorded in
   [17]http://www.w3.org/2013/01/17-xproc-minutes.html#action01]

  Review of open action items

   Norm: Alex, Henry, Norm, please report on your actions in email; suggest
   which ones are overtaken by events.

   <jfuller_> zip and unzip ... still draft

   <jfuller_> [18]http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html

   Alex: What's the status on the Processing Model document?

   Norm: The status is we're in Last Call and have comments from reviewers
   that we haven't addressed.

   Henry summarizes.

   Alex: Does it make sense to try to bring this to closure as fast as
   possible, even if other stuff is more interesting.

   Norm: Yes, that's the case.

   ->
   [19]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jan/0000.html

   Alex: I'll try to look at this after the call today.

   <scribe> ACTION: Norm to make XML Processor Profiles document an explicit
   agenda item [recorded in
   [20]http://www.w3.org/2013/01/17-xproc-minutes.html#action02]

  Review progress on use cases/requirements

   <jfuller_> [21]http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml

   Norm: Jim, I think you said you'd take a stab at it.

   Jim: I worked on the zip/unzip step instead. I did do some work, but it's
   not uploaded yet.
   ... The link above has notes from our f2f meeting. I'll try to get a
   revised document online by Tuesday for next week.

  Review of proposal to simplify parameters

   Norm: I think we were talking about Vojtech's inheritence proposal.

   Vojtech: The main idea was that maybe we could get rid of parameters
   altogether by inventing some sort of inheritence mechanism.
   ... Because we don't want to lose the "magical" behavior that they inherit
   from the pipeline.
   ... So options could possibly inherit from the calling context or maybe
   the other way around.
   ... This option "propagates down" if it's used. From a nested scope, for
   example.

   <jfuller_> initial Norm link on fixing parameters -
   [22]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0014.html

   Vojtech: It would be different to our current parameters but it would
   allow for things like having an XSLT step that has an option called
   parameters that's declared that it inherits from above. And by some kind
   of naming convention you could actually still use this magic that you're
   used to.
   ... The main idea would be to get rid of parameters concept alltogether
   and replace it with options.
   ... And with maps, the "parameters" option could be a map and those
   key/values could be inherited.

   Alex: Presumably we'd still need the with-param kind of construct.

   <jfuller_> last meeting minute param discussion -
   [23]http://www.w3.org/XML/XProc/2012/11/01-minutes.html#item04

   Vojtech: That's a question. Or some way to extend or override the map
   options.

   Alex: I think you could make that work in a number of ways. With-param
   could just be on the XSLT step.
   ... You could have a default parameter option and with-param could just
   modify the map associated with the default parameter option. We could
   support an option name.

   Vojtech: We'd have to be really careful with with-param and with-option
   and the order that we evaluate these things in. You could have with-option
   dynamically building the map and with-param updating it.
   ... That whole inheritence mechanism is simpler but also introduces some
   complexity, some side-effects that could be surprising if you don't really
   know what you're doing.

   Alex: Are you imagining the inheritence goes by the data-flow or by the
   structure?

   Vojtech: On the declare-option you'd say inherit=true and then when you
   use the XSLT step, if the parameters option is not set, it would look in
   the upper-contexts to find an option or variable with the same name and
   use that value.
   ... You could also do it the other way around, on a pipeline you can
   declare an option called parameters and inherit=true and it could
   propogate down.

   Norm: That's the same functionality, it's just a case of where you put the
   label, right?

   Vojtech: Well, yes, perhaps, but I think it's safer in some sense to
   propogate down because the author has more control. The other way around,
   using the steps could introduce surprises.

   Alex: Minus a whole bunch of details, I like this idea. I never liked the
   distinction between options and parameters. I didn't want to do it, but we
   didn't have an alternative.
   ... So I like this approach, but we need to make sure we get the details
   right.

   Vojtech: In my idea, it's all based on the option names.
   ... Any option name could be inherited.

   Alex: We need to decide if inheritence is a special thing that you turn
   on, or it's the default and you have a way to turn it off.

   Jim: I'd go for always inherited.

   Vojtech: If it's always turned on, it could help with unbound optional
   options.

   Alex: I think I'm in favor of always inheriting too.

   Norm: It only applies to steps inside compound steps so it's not too
   dangerous, I guess.

   Vojtech: If you really want something to be unbound, you should be able to
   make it explicit.

   Norm: But we don't have a syntax for that.

   Alex: But we'd need one, I think.
   ... We need to look at the details.

   Vojtech: I'm willing to dive a little deeper.

   Norm: I think that would be great.

   Henry: I'd like to see the same examples, if at all possible.

   Vojtech: The same?

   Henry: The same ones that Norm used in his proposal.

   Vojtech: Ok.

   Henry: I'm confident that either one of these or almost anything else
   would be an improvement.

  Support for document metadata?

   Norm attempts to summarize.

   Henry: We had this in the old markup pipeline engine, and the motivation
   in that case was output type. You could allow internal XSLT steps to set
   output type HTML and have that actually work at the end of the pipeline
   because it got passed along with the metadata.
   ... The bad news is that you have to think through the semantics about
   what kind of steps preserve this and what kind don't. It's not at all
   obvious, for example, that an XSLT step preserves the metadata. It may not
   make sense for the metadata to propagate.
   ... That may just be too hard a question to answer.

   Alex: It may also be the case that the pipeline author wants control over
   that.

   Henry: But we don't want them to have to think about that if they don't
   want to.

   Alex: But like inheritence, it might be the case that there needs to be a
   default and a way to specify the alternative.
   ... Output content type is a good example.
   ... I'm a little confused, because we had at least two proposals and then
   the f2f, and I'm not sure where we've gotten to.

   Norm attempts to explain again: we started with Vojtech's proposal for
   binary which required passing along the MIME type and we generalized that
   to document metadata.

   Alex: Right, but my proposal didn't require that.

   The chair expresses some confusion about the state of the binary
   proposals.

   <scribe> ACTION: Norm to put review of the binary proposals on the agenda
   for next week [recorded in
   [24]http://www.w3.org/2013/01/17-xproc-minutes.html#action03]

   Alex: Two things in my proposal are that XML is the only thing that flows
   through the pipeline. The binary is identified by reference. Everything is
   treated uniformly. It doesn't matter if the resource manager has a magic
   URI or if you point off into the ether of the universe

   Norm: Ok, my bad.

   Alex: I'd like to see some good use cases for document metadata.

   Norm: Fair enough.

   Henry: The other one that I recall that we recall that we used this for is
   preserving the character encoding. Which I can't remember if you can get
   from the infoset or not.

   Alex: There's a whole bunch of things that can be grouped into: how I got
   the original data vs. parameters needed for serialization. There's a whole
   bunch of metadata in there that's related. People might want to preserve
   how they read the data in how they write it and metadata is a good way to
   transport that form one place to another.

   Henry: The reason we did this for character encoding is that we invented
   an encoding that allowed us to preserve entity references.

   Vojtech: I have a question: all the metadata values or attributes that you
   mentioned look like magic metadata fields. But applications can also set
   things, like timestamps and labels, yes?

   Henry: Oh, absolutely, pipeline authors could come up with their own
   metadata.

   Jim: For non-XML it allows us to add metadata without changing the
   documents. It's like implementing a state machine without having the state
   in the documents.

   <scribe> ACTION: Norm to make sure document metadata stays on the agenda
   [recorded in [25]http://www.w3.org/2013/01/17-xproc-minutes.html#action04]

  Any other business?

   Alex: Who's going to XML Prague

   Jim: Everyone but Henry

   <scribe> ACTION: Jim/WG to discuss XProcathon at next telcon [recorded in
   [26]http://www.w3.org/2013/01/17-xproc-minutes.html#action05]

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Jim/WG to discuss XProcathon at next telcon [recorded in
   [27]http://www.w3.org/2013/01/17-xproc-minutes.html#action05]
   [NEW] ACTION: Norm to make sure document metadata stays on the agenda
   [recorded in [28]http://www.w3.org/2013/01/17-xproc-minutes.html#action04]
   [NEW] ACTION: Norm to make XML Processor Profiles document an explicit
   agenda item [recorded in
   [29]http://www.w3.org/2013/01/17-xproc-minutes.html#action02]
   [NEW] ACTION: Norm to put review of the binary proposals on the agenda for
   next week [recorded in
   [30]http://www.w3.org/2013/01/17-xproc-minutes.html#action03]
   [NEW] ACTION: Norm to send email polling for a different/better meeting
   time. [recorded in
   [31]http://www.w3.org/2013/01/17-xproc-minutes.html#action01]

   [End of minutes]

   --------------------------------------------------------------------------

    Minutes formatted by David Booth's [32]scribe.perl version 1.137 ([33]CVS
    log)
    $Date: 2013-01-23 13:04:12 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2013/01/17-agenda
   3. http://www.w3.org/2013/01/17-xproc-irc
   4. http://www.w3.org/XML/XProc/2013/01/17-minutes#agenda
   5. http://www.w3.org/XML/XProc/2013/01/17-minutes#item01
   6. http://www.w3.org/XML/XProc/2013/01/17-minutes#item02
   7. http://www.w3.org/XML/XProc/2013/01/17-minutes#item03
   8. http://www.w3.org/XML/XProc/2013/01/17-minutes#item04
   9. http://www.w3.org/XML/XProc/2013/01/17-minutes#item05
  10. http://www.w3.org/XML/XProc/2013/01/17-minutes#item06
  11. http://www.w3.org/XML/XProc/2013/01/17-minutes#item07
  12. http://www.w3.org/XML/XProc/2013/01/17-minutes#item08
  13. http://www.w3.org/XML/XProc/2013/01/17-minutes#item09
  14. http://www.w3.org/XML/XProc/2013/01/17-minutes#ActionSummary
  15. http://www.w3.org/XML/XProc/2013/01/17-agenda
  16. http://www.w3.org/XML/XProc/2012/11/01-minutes
  17. http://www.w3.org/2013/01/17-xproc-minutes.html#action01
  18. http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html
  19. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jan/0000.html
  20. http://www.w3.org/2013/01/17-xproc-minutes.html#action02
  21. http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml
  22. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Sep/0014.html
  23. http://www.w3.org/XML/XProc/2012/11/01-minutes.html#item04
  24. http://www.w3.org/2013/01/17-xproc-minutes.html#action03
  25. http://www.w3.org/2013/01/17-xproc-minutes.html#action04
  26. http://www.w3.org/2013/01/17-xproc-minutes.html#action05
  27. http://www.w3.org/2013/01/17-xproc-minutes.html#action05
  28. http://www.w3.org/2013/01/17-xproc-minutes.html#action04
  29. http://www.w3.org/2013/01/17-xproc-minutes.html#action02
  30. http://www.w3.org/2013/01/17-xproc-minutes.html#action03
  31. http://www.w3.org/2013/01/17-xproc-minutes.html#action01
  32. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  33. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 23 January 2013 13:05:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 23 January 2013 13:05:41 GMT