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

XProc telcon minutes 2009-11-12

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Thu, 12 Nov 2009 17:29:25 +0000
To: public-xml-processing-model-wg@w3.org
Message-ID: <f5bmy2rtzwq.fsf@hildegard.inf.ed.ac.uk>
Hash: SHA1

See http://www.w3.org/XML/XProc/2009/11/12-minutes.html

                                   - DRAFT -

                                XProc WG telcon

12 Nov 2009


   See also: [3]IRC log


          Paul Grosso, Alex Milowski, Henry S. Thompson, Toman Vojtech, Mohamed
          Zergaoui (in part)

          Norm Walsh

   Chair (pro tem)
          Henry S. Thompson

          Henry S. Thompson


     * [4]Topics
         1. [5]What can be used in [p:]use-when?
         2. [6]exclude-result-prefixes -- name and spec. correct?
         3. [7]Picking up use-when again
         4. [8]Default XML Processing Model draft
     * [9]Summary of Action Items

   HST: Agenda approved as posted, with DefProcMod next steps added at the end

   HST: Minutes of 29 October and 2 November approved nem con.
   ... Next meeting 19 November

What can be used in [p:]use-when?



   HST:  I proposed enumerating a set of guaranteed system properties and
   ... anything else has implement-dependent results

   TV: I'm happy with this -- messy in the spec., but works for implementors

   HST: We'll return to this when MoZ joins

exclude-result-prefixes -- name and spec. correct?

   TV: I raised this, but realised we had already dealt with it, and so I have
   no substantive problem
   ... MZ then raised the question of whether it was misnamed - - should it be
   called e.g. exclude-unused-prefixes

   AM: Not clear it's really necessary, but I'm OK with that name change

   TV: It's also in XSLT, what's it called

   AM:  The  name  in  the agenda is mistaken, its name in XProc today is
   ... In XSLT it's called exclude-result-prefixes

   TV: Since we're not producing result trees, that doesn't really carry over

   HST: I agree, that's a false friend

   AM: exclude-inline-prefixes is used on p:pipeline, p:library, p:declare-step
   as well

   TV: But it only applies to p:inline. . .

   AM:  We  can't detect use of prefixes in content, so -unused- could be

   TV: Simplest thing is not to change name, but clarify what it means

   [MZ joins the call]


   AM: What needs to be clarified?

   TV: We need to maybe expand on the very last sentence: "The XProc processor
   must include all in-scope prefixes that are not explicitly excluded."

   HST: It's not really right as it stands -- should be something like "must
   include   in   in-scope  namespaces  a  namespace  binding  for  every

   AM: But the elements have their full names, so even that's not necessary

   HST: But w/o it the serialisation will not know what prefixes to use

   AM: If the prefix property is used, it can provide that info

   HST: Where is that prop?

   AM: On the element -- it's optional

   HST:  The  motivation  is  the  same  as  for XSLT -- avoid clutter in

   AM: If you exclude a prefix that is only used in content, you can shoot
   yourself in the foot
   ... The serialiser will always be able to do the right thing -- quality of
   implementation -- saxon does the right thing

   HST: Two reasons we did this, I think: 1) [in scope namespaces] isn't empty,
   so that all serialisers can find the prefixes they might need, so that
   prefixes in content get the binding they need, and to prevent serialisers
   having to emit many many bindings lower down and 2) Given that to allow
   unwanted prefix bindings from being emitted.

   AM: Note we don't actually talk about used or not

   HST: Correct, and we shouldn't

   TV: Agree we shouldn't

   AM: So calling it -unused- would be misleading, because we don't impose that

   MZ: 1) Name is misleading, we need to fix it; 2) You may need to use the
   prefix for QName in content
   ... So you need to let in some prefixes on purpose
   ... So used/unused needs to be carefully considered

   HST: I hear consensus that we are not going to change what this attribute
   ... I like the name as it is because of the scoping issue

   AM: +0

   MZ: +0

   RESOLUTION: No name change

   <scribe> ACTION: HST to suggest wording to clarify the final sentence of
   section 5.12 [recorded in

   MZ: Include an example of how this doesn't exclude unused prefixes

   HST: I will consider that in my action

Picking up use-when again

   MZ: A good start, but not sufficient?
   ... Consider and, collections

   VT: That is covered in 3.9

   MZ: Yes, I missed that
   ... OK, I can live with HST's proposal
   ... Ah, what about variables?

   VT: Yes, we should add that

   RESOLVED  (tentative, pending NW agreement): Adopt HST's proposal from
   ov/0023.html and adding no variable bindings to the list in 3.9 of things
   which are empty/not there

   MZ: What about date-time ?
   ... XPath is required to give the same result every time you call it --
   could there be a problem here?

   MZ: XPath spec says current-date-time should give same result, but we don't
   guarantee that in XProc

   HST: Whatever mechanisms XPath impls use to guarantee should be independent
   of how they're being used
   ... so should work for us too
   ... So if NW's happy, he will change the spec., and if he isn't we'll hear
   from him

Default XML Processing Model draft


   HST: One substantive question
   ... What values do we use for fixup-xml-base and fixup-xml-lang?
   ... We added optionality to XInclude wrt these on request, because of the
   impact they were having on validation

   <MoZ> [16]http://www.w3.org/XML/XProc/docs/langspec.html#c.xinclude

   <MoZ> [17]http://www.w3.org/TR/xinclude/#base

   "An  XInclude  processor may, at user option, suppress xml:base and/or
   xml:lang fixup."


   AM: I am happy for these to be 'on' for the default proc. mod

   PG: So this sets something on the top of the bit you include

   HST: Yes, regardless of how much of the target you include

   PG: I agree that fixup should be the default

   HST: I will only observe that that's what we thought for XInclude 1.0, and
   then we got feedback which led to the [18]optionality erratum.

   PG: But the problem only arises if people are lazy

   HST: I think it can arise without any foul on anyone's part

   PG: Ah, yes, now I recall
   ... No problem with well-formedness

   HST: Right

   PG: The fixup only occurs at the infoset level
   ... and the problem arises when you serialise that and try to validate the

   HST: Right

   PG: The dpm is just for 'parsing' an XML Document, right?
   ... Doesn't cover RT's question about how a browser processes the output of

   AM: Correct. The DPM defines what the browsers will apply XSLT to
   ... so that's when XInclude gets done

   <MoZ> we should talk about processing sequence of document

   HST: This processing model is probably now misnamed

   HST: This is not a model which itself imposes conformance requirements
   anywhere in the XML stack
   ... rather it defines a term which other specs can now use, to mandate the
   processing so defined

   PG: We need to come back to this

   HST: We will

Summary of Action Items

   [NEW]  ACTION: HST to suggest wording to clarify the final sentence of
   section 5.12 [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [20]scribe.perl version 1.135 ([21]CVS
    $Date: 2009/11/12 17:28:39 $


   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/11/12-agenda.html
   3. http://www.w3.org/2009/11/12-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#agenda
   5. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#item01
   6. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#item02
   7. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#item03
   8. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#item04
   9. http://www.w3.org/XML/XProc/2009/11/12-minutes.html#ActionSummary
  10. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Nov/0010.html
  11. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Nov/0023.html
  12. http://www.w3.org/XML/XProc/docs/langspec.html#p.inline
  13. http://www.w3.org/2009/11/12-xproc-minutes.html#action01
  14. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Nov/0023.html
  15. http://www.w3.org/XML/XProc/docs/defproc.html
  16. http://www.w3.org/XML/XProc/docs/langspec.html#c.xinclude
  17. http://www.w3.org/TR/xinclude/#base
  18. http://www.w3.org/2004/12/xinclude-errata/#PEX16
  19. http://www.w3.org/2009/11/12-xproc-minutes.html#action01
  20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  21. http://dev.w3.org/cvsweb/2002/scribe/

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Thursday, 12 November 2009 17:30:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:47 UTC