See also: IRC log
AGREED: Minutes of 30 November accepted
Next meeting will be 14 December, no apologies as yet
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.
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
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. . .