accept previous minutes

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0080.html

AGREED: Minutes of 30 November accepted

next meeting

Next meeting will be 14 December, no apologies as yet

Subordination

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0081.html

MoZ: Main thing of the proposal was to separate source specification into three subordinate elements: external, internal and here
... Interesting point is that in each case the attributes are required
... Also, in the case of external, we could allow fallback to <here>

RT: Against a fallback mechanism -- we already have conditional processing and failure handling
... so I'd prefer to consider the proposal w/o that

HST: We'll separate that -- discussion of the basic subordination proposal:

RT: I like the orthogonality, but it's even more verbose than our current verbose proposal
... I would have liked <p:step type='xslt' stylesheet='step.port'.../>
... We already have one level of nesting, Murray's proposal would move us to two
... I'm worried we will need pages for even a simple pipeline
... XML is just not a good syntax for programming languages

HST: Verbosity is a problem -- first impressions matter. . .
... We don't want people to react as they did to XML Schema. . .
... Maybe we should start the defaulting discussion

AM: I like it, some names aside
... It's good for tools, it's good for annotation
... We're already verbose, this doesn't make things much worse

PG: Don't have a strong feeling - some worry about verbosity - if this is the right language we'll make it work
... If the more verbose solution is cleaner then I'm in favor

RL: Verbosity is an issue, but not against it as long as it's not too verbose

HST:Concerned about verbosity, but might be okay if we can get shorter via defaulting or something.

HST: Wants the common things to be easy to specify and not too verbose.

AM: Using subordinate elements allows you to construct a sequence of documents, which is a plus: new functionality

HST: Yes, but not obvious we have any such use cases. . .

RT: Even a mixture of <here> and <internal> . . .

AM: I think it's easy to come up with use cases

AV: Worried about verbosity, thinking about writing this kind of hurts. Fine with one level of nesting, but not happy with defaulting.
... Worried that we'll be unable to see what the pipeline means just by looking at it: where does data come from

AF: Not against verbosity as such, but worried about the impact on people. I'd prefer a simpler syntax in V1

MoZ: I'm concerned by the verbosity, but

MoZ: Currently p:input has 4 different models, and it's hard to understand the allowed co-occurences for beginners
... also hard for tools
... This is in tension with the verbosity
... I also like the sequence of documents support
... Also, easier to add documentation with the extra element
... Whereas currently we can't because of confusion with a 'here' document

<alexmilowski> That's an excellent point... too many attributes cause their own verbosity and easy-of-use problems

AM: Natural conflict between expressiveness and conciseness in the XML world
... RELAX has a compact syntax to address this issue
... Maybe we should consider a non-XML format or a mixture as per XQuery
... A well-understood grammar is the right foundation, shouldn't tackle verbosity right now

RT: Verbosity and defaulting aren't mutually exclusive -- even with a compact syntax you would want to default the primary connection between adjacent steps

HST: I'm very tempted to take RT's suggestion for secondary inputs, and allow you to write
... <p:step type='xslt' stylesheet='http://...'/>
... Only have to use subordinated elements (one or two) if you were computing the secondaries -- quite rare
... The subordination story is possible because we moved the magic port attribute onto e.g. the <p:for-each>

RT: Wrong, we gave it a fixed name

MM: Moz's point can be restated as "Moving to my proposal allows any schema language to express our grammar, instead of only one"
... Sympathetic to desire for conciseness, but that just means we shouldn't be using XML
... Ask RT to summarize what the roadblocks are

RT: No roadblocks, but verbosity is an issue (as well as fallback)

<alexmilowski> Clarification: I'm not worried about verbosity. We're already verbose.

HST: Straw poll: Shall we ask the editor to draw up a candidate draft encorporating MM's proposal?

In favor: 1111111

Opposed:

<PGrosso> I was not asleep--I concur.

ACTION to NDW: draw up a candidate draft encorporating MM's proposal.

Fallback

RT: Worried that it's extending the control structures by stealth
... We have mechanisms in the language for handling errors, so you can already catch an error in fetching a URI

MM: This is just an inexpensive (less verbose) way to handle a common error
... you'd use it as a debugging mechanism

RT: It's not a bug in your pipeline as such -- you want to see the error

MM: During development, you may want to test it w/o actually having the URLs in place

RT: Dubious about that. . .
... If you're not going to leave it during production, you could just start with a <here> and replace it with an <external>
... I don't know any programming language that work like this

HST: Suspend this, take it to email

Element and attribute names for subordination proposal

MM: Could accept portref instead of internal

AM: I don't like 'load', mild preference for 'document' over 'external'

RT: Would like 'pipe' instead of 'internal'

AGREED: Leave this to editor's discretion, but all are invited to argue in email for their preferred set of names

HST: Any other business?

MoZ: What about 'name' vs. 'port' for input?

MM, RT: Still open, not affected by our decision

MoZ: I would like to see documentation elements added explicitly at some point soon. . .