Re: The Scope of Step Names

/ Alex Milowski <alex@milowski.org> was heard to say:
| Erik Bruchez wrote:
|>
|> Alex Milowski wrote:
|>
|>  > 1. Step must be able to refer to other steps that are
|>  >    siblings (preceding and following) otherwise you
|>  >    can't connected steps at all.
|>
|> "Preceding siblings" would be enough IMO.
|
| And yet another example of where you wouldn't want this:
|
| I have a pipeline with steps:
|
|    validate -> xinclude -> transform
|
| but the input document doesn't validate.  So I quickly
| change, as an experiment, the input mappings to
|
|    xinclude -> validate -> transform.
|
| Oh, but that pipeline won't compile because the "preceding sibling"
| rule wasn't satisfied.  Now I have to change the element order
| to get it to compile.  But, as a user, the change was completely
| clear.

If the first pipeline relied on defaulting, the only obvious way to
make this change *is* to change the order of the steps.

| Yes, the order of the steps isn't the order of the flow... but I
| don't care about that because I'm just experimenting with the
| pipeline.
|
| When the pipeline gets more complex, this is going to get worse.  As
| a user, I'm going to get angry with the WG for that constraint.
|
| In all these messages, I'm trying to point out "good" reason why, when
| the compiler *can* figure this out, we shouldn't have an seemly
| arbitrary restriction for the user.

There's unquestionably a kernel of truth in that perspective.

                                        Be seeing you,
                                          norm

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