<scribe> scribenick: ht

<scribe> scribe: Henry S. Thompson

Agenda same as last week. . .

Plus vote to publish interim CR draft: http://www.w3.org/XML/XProc/docs/langspec.html, dated 10 May

Admin

RESOLUTION: Accept minutes of 7 March as published

Next meeting is 21 May

Regrets from HT

vote to publish interim CR draft

Norm distributed a pointer to his latest draft: http://www.w3.org/XML/XProc/docs/langspec.html, dated 10 May

We are not in immediate reach of a complete test suite

scribe: and it's been more than three months, so we should publish something

RESOLUTION: Ask the editor to publish the draft of 10 May as an interim CR draft as soon as convient

default XML processing model

PG raised some questions by email

PG: What's TimBL's current opinion wrt the pipeline model -- broken?

HT: It doesn't do what he wants, but he's not opposed to it
... because he's interested in the semantics of XML documents

PG: His version does look like the kind of top-down recursive story you told

HST: Right, and that's what I was trying to get at in the elaborated infoset story

Minutes of last week: http://www.w3.org/XML/XProc/2009/05/07-minutes.html

PG's emails: http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009May/0005.html

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009May/0006.html

PG: So there isn't anything in our current model which implements that kind of multi-threaded recursive story

HST: Correct

AM: Is it that there's a step or two missing, or is it more fundmental?

HST: More fundamental

<PGrosso> HST: The basic model of the proc model is infoset to infoset transforms.

<PGrosso> HST: It would be problematic to use our existing framework to do a standard recursive path.

http://www.ltg.ed.ac.uk/~ht/compositional.pdf

PG: In a full recursive-descent process, you can do things on the way down as well as on the way back up

HST: That's true, you can, but you typically don't

PG: What about namespace decls

HST: Good example, not context-free

AM: What about XSLT2 -- it would let you do a lot of that, wouldn't it?
... both down _and_ up

<PGrosso> HST: TBL's idea is to produce some kind of semantic object, not an infoset.

<PGrosso> HST: So there is a more fundamental reason that what TBL wants is not what our proc model does.

HST: [two kinds of semantics]

<PGrosso> http://www.w3.org/2001/tag/doc/elabInfoset/elabInfoset

PG: Surprised to see you mention XInclude, XML Sig, XML Encryption, but not xml:id and xml:base

HST: Good question, and I think you're right on both counts
... Leaving out xml:base and xml:id was accidental
... xml:base comes for free with XProc
... but xml:id does not, in two ways:
... 1) We didn't require the xinclude step to recognise xml:ids as anchors for uris with fragids

PG: And wrt anchors there are further questions wrt DTDs and XSDs
... it's all intertwingled, and we appear to need to de-confuse the order
... to say nothing of adding in recursive descent

HST: coming back to XProc vs xml:id
... we don't currently say that e.g. when parsing a character stream to produce an infoset, XProc processors should set xml:id attr IIs to have type ID
... or when we introduce xml:id attrs via e.g. add-attribute, that they should get that type
... does this matter? Is it detectable whether we do or not?
... What if we write type-aware XPaths, which look for type ID -- should/do/how do we know if they match xml:id?
... Need Norm for that
... Coming back to Decryption and signature verification
... [backing off]
... Good news: Xinclude is itself recursively specified -- so we don't have to implement the fixed-point detection for it in XProc
... So maybe we _could_ write an XProc pipeline which implemented a default model:
... [Straw man] An XProc pipeline consisting of an XInclude step
... (modulo some uncertainties wrt xml:id)

PG: So all we need from a small-s schema is IDness?

HST: That is the problem alright
... There's a chicken and egg problem
... Imagine two stages: we publish an DXPM spec; we publish a new edition of XInclude which references the new DXPM spec
... We won't get everything we want until the second step

PG: Do we have to worry about schemas?

HST: Yes, because of the way we wrote XPointer wrt IDness

PG: Any other way?

HST: External entities

PG: They get expanded, don't they?

HST: Not by all the browsers

PG: Assuming they have been expanded, there's nothing except IDness you need from schemas, in order to resolve XPointers and do xinclude
... assuming only element and framework

HST: [optionality/extensibility, again]
... Open questions: 1) What about the flexibility in the XML spec itself? Do we want to require the 'full' well-formedness parse?
... 2) Parameterisable/extensible/fixed+optional --- or not?
... If it were up to me, I'd say "yes" to 'full' wfp

PG: I thought you didn't want to bring in the DTD?

HST: No, just not all the _other_ schema languages

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)

Succeeded: s/20/21/
Found ScribeNick: ht
Found Scribe: Henry S. Thompson
Default Present: Ht, PGrosso, Alex_Milows, MoZ, Vojtech
Present: Henry Paul Alex Mohamed
Agenda: http://www.w3.org/XML/XProc/2009/05/07-agenda.html
Got date from IRC log name: 14 May 2009
Guessing minutes URL: http://www.w3.org/2009/05/14-xproc-minutes.html
People with action items: