Re: Alternative to x!y (proposal)

At 10:05 AM 8/28/2006 -0400, Norman Walsh wrote:
>| 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.

Yes, but that error is described in prose. Therefore the error handling
must be built into implementations. Not onerous, but still, there it is.


>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 :-)

That would be an error that the XML validator could catch. No extra code
to write, you get that for free by writing a DTD or Schema. That was a
significant part of what I was saying.

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

Hmmm. And to my eyes it becomes a lot clearer. How do others feel?


>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.)

I don't feel that it is "bending" anything. This is a straightforward
design decision. I am guided by Maler & ElAndaloussi as well
as Rubinsky on this.


> 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.

Straightforward, I'll agree. But absolutely free if you design a content model
in any of the existing schema languages. And I suspect that authoring tools
would find it easier to offer author guidance on a content model rather
that prosaic co-constraints.

Regards,

Murray