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

XProc Minutes 13 Nov 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 13 Nov 2008 12:33:42 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2k5b734zt.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/11/13-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 129, 13 Nov 2008

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Vojtech, Henry, Mohamed, Paul, Richard, Alex

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 20 Nov 2008
         4. [8]Close remaining last call issues
         5. [9]Issue 053: Creating elements
         6. [10]Issue 055: Storing binary data
         7. [11]Issue 057: p:namespace-rename
         8. [12]issue 062: No path specified on p:directory-list
         9. [13]Issue 063: Versioning and nested declarations

     * [14]Summary of Action Items

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

  Accept this agenda?

   -> [15]http://www.w3.org/XML/XProc/2008/11/13-agenda

   Accepted

  Accept minutes from the previous meeting?

   -> [16]http://www.w3.org/XML/XProc/2008/10/tpac-minutes

   Accepted.

  Next meeting: telcon 20 Nov 2008

   Vojtech gives regrets.

  Close remaining last call issues

   -> [17]http://www.w3.org/XML/XProc/2008/08/lastcall/comments.html

  Issue 053: Creating elements

   Proposal: close with no action

   Vojtech: I agree, but I think some people might find it strange.
   ... But a new step would amount to the same amount of code, so it's fine.

   Accepted.

  Issue 055: Storing binary data

   Norm thinks that a custom method on p:store is probably sufficient, binary
   data isn't the focus of our language.

   Mohamed: Norm used content-type, but we don't have that attribute

   Norm: I meant "media-type" I guess.

   Mohamed: So it wouldn't be interoperable. So it'd be <p:store
   method="foo:binary"> ...

   Norm: yes.

   Alex: Are we putting something like this in the document.

   Norm: I was proposing to add a note.

   Mohamed: A parallel question: for p:data and c:data it's content-type,
   that's probably why there was confusion.
   ... Where does this difference come from?

   Alex: HTTP uses a content-type header and all the internet-speak uses
   media-type. The serialization parameter is called media-type.

   Mohamed: The value is the same?

   Alex: Yes, the value of the media-type header is a content-type.
   ... We could decide to be consistent and use media-type throughout and be
   inconsistent with the HTTP RFC.

   Mohamed: I thought the difference might be that content-type also has a
   charset value.

   Alex: That's a good point. Maybe that's why it's called content-type vs.
   media-type, I'm not sure.
   ... The names should be separate because the content-type can have
   parameters.

   Norm: Yes, we have two different names, but I think we're going to leave
   them the way they are.

   Mohamed: I just wanted to make sure that we don't mix the two.

   Proposal: No change to the spec, but add a note about using an extension
   to p:store to save binary data.

   Accepted.

  Issue 057: p:namespace-rename

   Norm summarizes Vojtech's mail

   Norm: I don't feel strongly about it, but it does seem a little
   inconsistent.

   Alex: I like the apply-to change, but I'd use the values "elements" and
   "attributes" without "-only"

   Proposal: Rename element-only to apply-to as suggested.

   Accepted.

  issue 062: No path specified on p:directory-list

   Norm: Anyone remember why we made path optional?

   Henry: No, I don't, and it doesn't seem terribly plausible. I think we
   should just make it required.

   Alex: How do you get the current directory of the pipeline or the source
   document?
   ... Maybe this meant the current directory the document is in or the
   current directory of the application?

   Henry: You can use the base-uri function. It might be reasonable to say
   that it peels back to the last forward-slash in the base URI.

   Vojtech observes that a relative directory is resolved against the step,
   so it works out to the same thing as specifying ""

   Henry: I do think we need some words that say that everything after the
   last slash is discarded.

   <alexmilowski> ./

   Richard: I don't think we need to do that, we could just say that it's the
   empty string by default.

   Norm: Can't we just make it required?

   Richard: We can say that if it's not specified it's "."

   Mohamed: I think it makes more sense to make it required.

   Vojtech: There was a similar problem with p:store, which we fixed by
   making href on p:store required.

   Proposal: Make it required.

   Mohamed: Is it possible to add a note to say that use "." for the current
   directory.

   Norm: Sure, we can do that.

   Richard: It isn't the current directory, it's the directory you get by
   resolving "." against the base URI.

   Henry: We needed to add that to the Markup Technologies pipeline, but not
   here, not today.

   Richard: Since "." doesn't give the CWD, I think it's much less common.

   Norm: So the proposal is to make it required and not add the note.

   Accepted.

  Issue 063: Versioning and nested declarations

   Norm summarizes

   Some discussion of whether or not this is really a problem and if it would
   in fact be a feature for this case to work.

   Henry: This is similar to the problem of having two different schemas for
   the same namespace in the same context.
   ... I think it's too late to figure out how to cope with this in this
   version of this language.

   Vojtech: I agree

   Henry: Somewhat regretfully, we have to say this isn't going to be
   properly addressed until we get to V2.0

   Norm: Vojtech's point is a good one, we could make this work, but not in
   V1.0

   Mohamed: I'm still confused. If you have a V1 processor processing the
   pipeline so it'll start with a V1 library.

   Norm: It just seems to me that asking the implementation to change it's
   idea of what the pipeline library is half way through invites
   interoperability issues and mayhem.

   Henry: The isn't it better to say that a processor may through an error if
   it encounters an import of a new version "too late" where "too late" is
   implementation defined.

   Vojtech: Why would we have to go back and change the declaration? The
   import statement is always in scope for a library or compound step.

   Norm: The XProc library is special, it's allowed to include
   redeclarations.
   ... Maybe the best we can do is what Henry suggested.

   Alex: So there are two issues, the ability to throw an exception, and if I
   load this, then what happens with optional options.

   Norm: I think the question of optional options are fully covered by the
   spec.

   Henry: The only question we didn't answer was what we should do in the
   nested case.
   ... I think the simplest thing to do is just say that processors are
   allowed to reject this.
   ... Asking for complete consistency about all possilbe scenarios seems
   premature. We've got a consistent story that we know we want to work: if
   you import the library up front.
   ... Beyond that, I think we should just say that processors can reject it
   if they want.

   Mohamed: I'm ok with that.

   Vojtech: I'm ok too.

   Proposal: Processors are allowed to reject the import of a V.next library
   if it occurs "too late", where too late is implementation defined.

   Accepted.

   Norm will produce a CR draft. Henry will arrange a transition call.

   Adjourned

Summary of Action Items

   [End of minutes]

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

    Minutes formatted by David Booth's [18]scribe.perl version 1.133 ([19]CVS
    log)
    $Date: 2008/11/13 17:31:44 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2008/11/13-agenda
   3. http://www.w3.org/2008/11/13-xproc-irc
   4. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#agenda
   5. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item01
   6. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item02
   7. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item03
   8. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item04
   9. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item05
  10. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item06
  11. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item07
  12. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item08
  13. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#item09
  14. file:///projects/w3c/WWW/XML/XProc/2008/11/13-minutes.html#ActionSummary
  15. http://www.w3.org/XML/XProc/2008/11/13-agenda
  16. http://www.w3.org/XML/XProc/2008/10/tpac-minutes
  17. http://www.w3.org/XML/XProc/2008/08/lastcall/comments.html
  18. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  19. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 13 November 2008 17:34:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 November 2008 17:34:30 GMT