Re: initial comments

/ James Fuller <james.fuller.2007@gmail.com> was heard to say:
| I had a chance to go through the latest XProc draft and wanted to
| scratch out some thoughts here.

Thanks!

| * should be consistent when indicating when a step takes multiple
| inputs an/or multiple sequences...e.g. p:join-sequences  uses
| <p:input port="*" sequence="yes"/> and p:subsequence does something
| else...multiple input elements should be represented as well.
|
| * might be worth outlineing how p:join-sequences will aggregate (e.g.
| are documents serially aggregated or actually merged together)

It turns out that p:join-sequences isn't necessary, but I agree that
we need to be more specific about how aggregation is performed.

| * p:subsequence should be clarified: e.g. does an entire document get
| aggregated to output when test is true.

The p:subsequence component is going to be revised.

| * maybe useful to have http separated out e.g. http-get as required

I would have expected p:document to be sufficient for simple HTTP
gets. Or are you thinking of something else?

| * any thoughts on relation of xpointer with Xproc (e.g. wherever there
| is a select attribute)?

XProc takes XPath 1.0 expressions, not XPointer expressions. There's
no provision for more extended XPointer expressions. Nor is there a
standard for the more extended XPointer syntax. :-(

| * circular references with p:pipe needs clarification

Circular references are not allowed. What additional clarification
were you thinking of?

| * need to clarify sequences of documents usage for p:inline

You can't put a sequence of documents in p:inline, you have to use
a sequence of p:inlines.

  <p:input ...>
    <p:inline>...</p:inline
    <p:inline>...</p:inline
    <p:inline>...</p:inline
  </p:input>

How those three inlines are aggregated is one of the things that 
needs to be clarified.

| * verbatim copy for p:identity needs to be a bit clarified.

How so?

| * should there be default input and output names for default input and
| output ports?

We decided not to base the defaulting strategy on names, though we've
adopted the convention that the primary input will be on a port called
"source" and the primary output on a port called "result".

| * p:xslt: should there be some namespace binding to define which XSLT
| processor to use....

That's an implementation extension, I think. And it belongs on the
p:declare-step, I think. I wouldn't want one instance of p:xslt to use
Xalan and another in the same pipeline to use Saxon. At least, I don't
think I would.

| also if so should  there should be a p:option to
| determine any processor specific switches. Can think of this type of
| thing cropping up with xml parser and various other steps that do work
| (and their exists multiple processors)

Perhaps. Or perhaps those are better handled with extension elements:

  <p:declare-step type="p:xslt" ex:impl="Saxon">
    ...
  </p:declare-step>

  <p:xslt>
    <ex:saxon>some saxon opts</ex:saxon>
    ...
  </p:xslt>

| * thoughts on an optional p:tidy or p:tag-soup?

Both good ideas.

| * xsl:for-each adds a bit of complexity, might be useful to place this
| as an optional step?

I don't think I want any of the core language features to be optional.
And yes, it's a bit of complexity, he says, having just gotten his
impl running them again :-)

| * I am not sure about p:try p:catch, try/catch has never felt right
| with these kind of approaches.....once again possible optional step

I think we need some error-recovery mechanism. Do you have something
else in mind?

| will have more thoughts later on in the week; with more pickier
| (spelling, language, etc) items

Looking forward to it.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.