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

Re: Naming ports vs. naming documents

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 28 Apr 2006 12:50:58 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <871wvhprt9.fsf@nwalsh.com>
/ Alex Milowski <alex@milowski.org> was heard to say:
| I think if we make a tedious language, we will not be successful.  While
| we should plan for GUIs, simple things need to be simple. 

Fair enough. And on the other end of the spectrum, we don't want to
put so many defaults and shortcuts into the concrete syntax that it
becomes difficult to understand what's going on. I think design goal
number 10 from the XML spec applies:

  10. Terseness in XML markup is of minimal importance.

| So, for example, chaining XSLT transforms together should have some
| defaults:
| <step type='xslt'>
|    <input name="stylesheet" ref="..."/>
| </step>
| <step type='xslt'>
|    <input name="stylesheet" ref="..."/>
| </step>

I'm unconvinced. At the very least, I think we should design a wholly
explicit syntax first and then decide what, if any, defaults should be
applied. I'll be more easily convinced if we can frame them as general
rules rather than an elaborate series of exceptions.

| Of course, the problem is, does that XSLT output one document or many?
| Does it take in one or many?

I think that's something we decide on a component-by-component basis.
For example, I think the XSLT 1.0 component should take a single
document and a single stylesheet as input and it should produce a
sequence of documents on its output.

That raises the question of what a processor should do if a user bolts
a component that produces a sequence onto a component that accepts a
single document. I can think of three possibilities, in roughly my
initial order of preference:

1. Dynamic error; if the pipe actually contains a sequence, HCF
2. Static error
3. Syntactic sugar for a for-each

                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Friday, 28 April 2006 16:51:11 UTC

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