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

XProc Minutes 22 Jan 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 22 Jan 2009 13:12:54 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ocxz43bt.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/01/22-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

Meeting 134, 22 Jan 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Paul, Mohamed, Henry, Vojtech, 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: telcon 29 Jan 2009?
         4. [8]CR comments
         5. [9]004: preserving base URI
         6. [10]015 p:uuid question
         7. [11]022 p:http-request default method
         8. [12]023 p:http-request - POST with no c:body
         9. [13]035 instance name visible to custom step
        10. [14]017 p:xquery and XQueries that cannot be evaluated.
        11. [15]021 Replacing the document node in p:string-replace
        12. [16]025 p:unescape-markup "namespace"
        13. [17]Any other business?

     * [18]Summary of Action Items

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

   Considering which issues to discuss (apologies again for not providing
   more notice; I'll try to do better next week): 004 (again) 015, 022, 023,
   035.

   More possibilities: 017, 021, 025, 026, 027

  Accept this agenda?

   -> [19]http://www.w3.org/XML/XProc/2009/01/22-agenda

   Accepted.

  Accept minutes from the previous meeting?

   -> [20]http://www.w3.org/XML/XProc/2009/01/08-minutes

   Accepted.

  Next meeting: telcon 29 Jan 2009?

   Paul gives regrets.

  CR comments

   -> Topic: Next meeting: telcon 29 Jan 2009?

   -> [21]http://www.w3.org/XML/XProc/2008/11/cr-comments/

  004: preserving base URI

   Henry: This whole thing is hugely complicated and it's not made at all
   easier by the fact that none of the relevant XML specs are really
   consistent with one another.
   ... It's not the case that it's easy for us to say that we should do it
   like everyone else, because they all do it differently.
   ... The Infoset says that if you assemble a document out of multiple
   general entities, the base URI changes accordingly.
   ... But it doesn't have a serialization or any sort of base URI fixup.
   ... On the other end of the spectrum, XInclude (V1) said that you had to
   insert xml:base attributes and change the infoset.
   ... In the middle, we have XSLT which will change the base URI if you add
   xml:base attributes, but can't preserve them when copying.
   ... So the one observation that Richard made that I point to in this
   email:

   ->
   [22]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html

   scribe: is that XML Base is a bit like character entities or namespace
   declarations. They're there in order to effect the infoset, but they're
   not part of the document. They're metadata.
   ... And therefore, there's no guarantee that they're going to be there
   when you serialize.
   ... So it's not completely outrageous to think that you might loose base
   URI information when you serialize.

   Alex: It seems that if you delete the xml:base attribute, then you get
   what you deserve if you really wanted to preserve the base URI.

   Henry: At the moment, I'm inclined towards the position that we should
   sort of follow XSLT: if you delete an xml:base attribute, it does not
   change the base URI attribute of the element.

   Alex: But you lose it if you serialize.

   Henry: Yes. In the same way that a parser takes account of general entity
   structure and the base URIs, but they won't be preserved when yous
   serialize.
   ... What Richard eventually conceded, is that if we leave the spec the way
   it is, he can still serialize between steps and carry the base URI
   out-of-band.

   Straw poll: Removing the xml:base attribute (a) removes the base URI
   property from the infoset or (b) does not change it.

   Results: Five for (b) no change, 1 abstention.

   Vojtech: If I really want to remove the base URI information, then I
   should ... add an xml:base attribute with the value from the parent.

   Some discussion of serialization.

   Henry: Are we also in agreement that we do have to update the spec
   everywhere you can do something that can add or change the value of an
   attribute to say that if the attribute is added/changed is the xml:base
   attribute, this causes a change to the XML base property.

   Norm: Anyone who disagrees?

   None heard.

   <scribe> ACTION: Norm to edit the spec so that we say that any change to
   xml:base or adding an xml:base does change the underlying infoset
   property. [recorded in
   [23]http://www.w3.org/2009/01/22-xproc-minutes.html#action01]

  015 p:uuid question

   Vojtech: The question of whether it generates one UUID or many has been
   answered: it generates one UUID.
   ... The remaining question is whether this step needs additional options
   or parameters.

   Norm: Do we know what the parameters/options are?

   Some discussion of the various types of UUID.

   Norm: I think the question is, do we leave other versions
   implementation-defined, or do we try to add parameters/options to make it
   interoperable.

   Alex: I think we should provide the options.

   Vojtech: In Java you can generate type 3.
   ... I was thinking maybe it was sufficient to do for p:uuid what we do for
   p:hash

   Norm: To be honest, I think for V1 we should just make the parameters that
   are needed for other UUID formats implementation defined.

   More discussion about the virtues of parameters instead of extension
   attributes.

   Vojtech: Why don't we just say that the only supported version is version
   4.

   Alex: I guess I could live with implementation defined.

   Proposal: Implementations must support version=4, support for other
   versions (and how options/parameters are provided for those versions) is
   implementation-defined.

   Accepted.

  022 p:http-request default method

   Norm: If you don't specify a method on p:http-request, do we work it out
   dynamically or do we make method required?

   Alex: I think we should make it a required attribute.

   Norm: That's what I thought too, in email following up.

   Proposal: The method is required, it is an error to attempt to use
   p:http-request without a specified method.

   Accepted.

  023 p:http-request - POST with no c:body

   Vojtech: I think that's clear now, you can do a post a body.

   Norm: Is there any distinction between no c:body and an empty c:body?

   Alex: I think if you specify an empty body, you get a content-length: 0,
   and if you don't specify a body, you don't get any entity body.

   Proposal: Yes, you can have a POST with no c:body element.

   Accepted.

  035 instance name visible to custom step

   Norm: I think James is asking for the ability to get the step name without
   passing it as a separate option. Looks like creeping featurism to me: not
   in V1?

   Proposal: Not in V1.

   Accepted.

  017 p:xquery and XQueries that cannot be evaluated.

   Vojtech: I thought that in the XQuery step we should have an error for
   reporting bad XQuery.

   Norm: A particular error code for "couldn't understand the query"?

   Vojtech: Yes, I think we could put all the possible errors in one error
   code.

   Alex: Could we add an error for "unable to process input", we could use it
   for XSLT, XQuery, XML Formatter. I could use it for a SPARQL step if I had
   one, etc.
   ... These could apply to the validator steps as well.

   Proposal: A generic error for "unable to process input/input format
   wrong/etc." that all steps (including custom steps) can throw when
   appropriate.

   Accepted.

  021 Replacing the document node in p:string-replace

   Vojtech: I was wondering what happens if you replace the document element
   with an empty string in p:string-replace.
   ... Does this call XD0001?
   ... One of the answers was 'yes'.

   Norm: Yep, that works for me.

   Vojtech: I was trying to write a test for this.

   Norm: We don't require processors to produce exactly the right errors, but
   it's still good to be clear.

   Proposal: Close without action.

   Accepted.

  025 p:unescape-markup "namespace"

   Vojtech: You can have a wrapper element which if you unesacpe the content
   then you get five elements inside. The text about unescape-markup talks
   about a single document element.
   ... I think that phrasing should be changed so that it covers the case
   where unescaping gives five elements (or no elements) in the wrapper.
   ... I think it should be applied to each of the elements in the wrapper.

   Alex: The way I look at this is, when you provide the default namespace,
   it's like you're wrapping the whole thing in a pseudo-element that you can
   throw away.
   ... that's effectively the behavior.

   Norm: It sounds like this is mostly editorial, handling the case where
   there are multiple or no elements.

   Vojtech: Issue 080 is related: if you specify a namespace but the
   unescaped content already has a default namespace.
   ... Or if the element declares other namespaces. Are they effected?

   Alex: If you take the escaped content, treat it as if it was wrapped in an
   element with a default namespace declaration, and then take it's children.
   That's what should happen.

   Norm: I think the practical upshot is that the answer is that if there are
   default namespace bindings in the content, those bindings "win" and it has
   no effect on any other namespace declarations.

   Vojtech: The spec currently gives the impression that it overrides the
   defalut.

   Norm: I agree, the spec is confusing.

   Proposal: Close 025 with no action, close 080 with an action to the editor
   to clarify the spec so that any specified namespace clearly does not
   override any explicit declarations in the escaped content.

   Vojtech: Part of my question in 025 was about the case where you have no
   root elements or more than one.

   Norm: Right.

   Proposal: Close 025 with an action to the editor to clarify the case where
   unescaping produces no elements or more than one element, close 080 with
   an action to the editor to clarify the spec so that any specified
   namespace clearly does not override any explicit declarations in the
   escaped content.

   Accepted.

   <scribe> ACTION: Norm to edit the spec to fix 025 and 080. [recorded in
   [24]http://www.w3.org/2009/01/22-xproc-minutes.html#action02]

  Any other business?

   None heard.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Norm to edit the spec so that we say that any change to
   xml:base or adding an xml:base does change the underlying infoset
   property. [recorded in
   [25]http://www.w3.org/2009/01/22-xproc-minutes.html#action01]
   [NEW] ACTION: Norm to edit the spec to fix 025 and 080. [recorded in
   [26]http://www.w3.org/2009/01/22-xproc-minutes.html#action02]

   [End of minutes]

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

    Minutes formatted by David Booth's [27]scribe.perl version 1.133 ([28]CVS
    log)
    $Date: 2009/01/22 18:11:32 $

References

   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/01/22-agenda
   3. http://www.w3.org/2009/01/22-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#agenda
   5. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item01
   6. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item02
   7. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item03
   8. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item04
   9. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item05
  10. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item06
  11. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item07
  12. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item08
  13. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item09
  14. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item10
  15. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item11
  16. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item12
  17. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item13
  18. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#ActionSummary
  19. http://www.w3.org/XML/XProc/2009/01/22-agenda
  20. http://www.w3.org/XML/XProc/2009/01/08-minutes
  21. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  22. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html
  23. http://www.w3.org/2009/01/22-xproc-minutes.html#action01
  24. http://www.w3.org/2009/01/22-xproc-minutes.html#action02
  25. http://www.w3.org/2009/01/22-xproc-minutes.html#action01
  26. http://www.w3.org/2009/01/22-xproc-minutes.html#action02
  27. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  28. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 22 January 2009 18:13:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 January 2009 18:13:39 GMT