Re: Alternative to x!y (proposal)

/ Murray Maloney <murray@muzmo.com> was heard to say:
| 1.) Let's not try to "decide" on naming of attributes just yet.
| Assuming that we use two attributes, we only need placeholder
| names for now. We can/should decide final names later.

Sure, but if we quickly reach consensus on placeholder names, so much
the better.

| Well, to save us from having to explain:
|
| 	<p:input port="document" href="http://example.com/input.xml"
| step="step" source="result">
| 		<here:document>Here document</here:document>
| 	</p:input>

That's an error. You can specify at most one form of binding.

| I would prefer that we make these three different elements, or use
| nested elements:
|
| 	<p:input port="document">
| 		<p:include      href="http://example.com/input.xml"/>
| 	</p:input>
| or	<p:input port="document">
| 		<p:from         step="step"              output="result"/>			
| 	</p:input>
| or	<p:input port="document">
| 		<p:here>Here document</p:here>
| 	</p:input>
|
| Of course, we can name these elements/attributes appropriately later.
| And we can use these same child elements on declare-[in|out]put.

We could go this way, but we'd still have to explain the analogous markup:

  <p:input port="document">
    <p:include      href="http://example.com/input.xml"/>
    <p:from         step="step"              output="result"/>			
    <p:here>Here document</p:here>
  </p:input>

And that would be an error too :-)

To my eyes, the extra level of wrapper just makes the pipeline harder
to understand and more tedious to write.

| I know that it is a lot of extra syntax to achieve what could be encoded
| more succinctly. But my guess is that it would be easier to write the
| handlers for these four elements than it would be for that one that y'all
| are talking about now. Of course, I am not an implementor so I could
| be wrong about that. But it sure seems like it would be easier to explain
| the constraints on sub-elements than co-constraints on attributes, and
| existing schema languages can describe sub-element constraints, whereas
| the attribute co-constraints cannot be so described.

I would like our syntax to be amenable to schema validation, but I
don't feel compelled to bend it to make it so. (In fact attribute
co-constraints are straightforward to describe with RELAX NG, but
that's neither here nor there.)

From an implementation perspective, I don't think it makes much
difference. The tricky programming is what to do when all the inputs
are valid :-), rejecting the invalid ones is reasonably
straightforward in either case.

                                        Be seeing you,
                                          norm

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