XProc WG telcon

12 Nov 2009


See also: IRC log


PGrosso, Ht, Vojtech, Alex_Milows, MoZ
Henry S. Thompson (pro tem)
Henry S. Thompson




<MoZ> Hi ht

<MoZ> there's really a Meeting ?

I Vojtech comes back, yes

<MoZ> s/I/If/ ?


<scribe> Scribe: Henry S. Thompson

<scribe> ScribeNick: ht

<alexmilowski> *sigh*

<alexmilowski> fighting with the bridge


code is 97762

<alexmilowski> it just dropped me...

Mohamed, you joining us?

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

<MoZ> gonna join in 5 to 10 minutes max

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

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

<Vojtech> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Nov/0010.html


HST: I proposed enumerating a set of guaranteed system properties and functions
... 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 exclude-inline-prefixes
... 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: e-i-p 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 misleading

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


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 inscope-namespace"

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 serialisation

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] and [2]

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 semantics

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 _means_
... I like the name as it is because of the scoping issue

AM: +0

MZ: +0

<alexmilowski> grrr...

RESOLUTION: No name change

<scribe> ACTION: HST to suggest wording to clarify the final sentence of section 5.12 [recorded in http://www.w3.org/2009/11/12-xproc-minutes.html#action01]

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

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 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Nov/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?

TV: 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 bein gused
... 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 these on request, because of the impact they were having on validation

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

<MoZ> 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

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

<MoZ> <p:for-each

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

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 XSLT
... AM said the DPM defines what the browsers will apply XSLT _to_
... so that's when XInclude gets done

HST: This processing model is probabaly now misnamed

<MoZ> we should talk about processing sequence of document

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 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 http://www.w3.org/2009/11/12-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/11/12 17:04:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/I/If/ ?
Succeeded: s/sentence/sentence of section 5.12/
Succeeded: s/si/is/
Found Scribe: Henry S. Thompson
Found ScribeNick: ht
Default Present: PGrosso, Ht, Vojtech, Alex_Milows, MoZ
Present: PGrosso Ht Vojtech Alex_Milows MoZ
Agenda: http://www.w3.org/XML/XProc/2009/11/12-agenda.html
Got date from IRC log name: 12 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/12-xproc-minutes.html
People with action items: hst

[End of scribe.perl diagnostic output]