Re: Alternative to x!y (proposal)

Dear,

Answer inside Murray's email


On 8/26/06, Murray Maloney <murray@muzmo.com> wrote:
>
> I missed this discussion because I was away on business w/o a laptop.
> I'm glad that I got to read it in one go because it made it easier for me
> to see what was bugging me about where y'all are going with this.
>
> I'd like to make two comments.
>
> 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.


Agreed +1

2) If we do use two attributes, then this element is starting to look weird
> to me.
>
>         <p:input port="document"     href="http://example.com/input.xml"/>
> or
>         <p:input port="document"
> step="step"              source="result"/>
> or
>         <p:input port="document">
>                 <here:document>Here document</here:document>
>         </p:input>
>
> 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>
>
> 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>


Ok, let's analyse the pros and cons :
= A. Pros =
== I. Declaration/Instanciation ==
With this proposal, declaration is weared by <p:input>
and instanciation is inside it.

== II. Documentation ==
I would like to have a simple mechanism for documenting ports.
The simplest and clearer is in this proposal with a nested element
<p:documentation/>

== III. Base element ==
If like Henri proposed, the @href can contain a LIST of xs:anyURI, we can
imagine to have the use of xml:base or any specific attribute to say all
those stuff are taken relatively to this url, so this had an extra attribute
only for href case. (ok it's a weak argument, but the idea behind is that is
seems like each construct has special cases which don't overlap)

== IV. Forget of attribute ==
If a user, which we now all, DO READ ALL THE SPECS, in the PREVIOUS syntax,
write something like
<p:input port="document"/>
which is perfectly allowed.

Are we sure, that the least surprise is to have in this case :
* an empty sequence of document ?
* a sequence of empty document ?
* a shortcut to say to take the last result of last output (in a
minimization case) ?
* an error ?

The pros for Murray's proposal in this case, is that <p:input
port="document"/> is ONLY the declaration part and that the port is NOT
instanciated.

== V. Here document case ==
=== 1. Correction ===
A small correction on your proposal
<p:input port="document">
     <here:document>Here document</here:document>
</p:input>
versus
<p:input port="document">
     <p:here><here:document>Here document</here:document></p:here>
</p:input>
(see the extra root here:document)

=== 2. Sequence ===
As Henri, pointing this out, we need a <p:sequence> element for here
document.
And because of the simple case pointed out by Norm with

<a/>
<?pi?>
<b/>

We need a wrapper around documents for sequence
so with Murray's proposal

<p:input port="document">
  <p:documentation> This is the documentation of the port
"document"</p:documentation>
  <p:sequence>
    <p:documentation> This is the documentation of the here sequence which
could travel by copy/paste</p:documentation>
    <p:documentation> Extra documentation for the first element of the
sequence </p:documentation>
    <p:here>
       <a/>
    </p:here>
    <p:documentation> Extra documentation for the second element of the
sequence </p:documentation>
    <my:output-debug-on-reach>We are in the middle of the
sequence</my:output-debug-on-reach>
    <p:here>
      <?pi?>
      <b/>
    </p:here>
  </p:sequence>
</p:input>

As pointed out by Murray, I don't care with the name, only the concepts are
important.
Of course, it is verbose, but can we really do this with fewer element and
still stay as extensible and understandable ?

= B. Cons =
== I. Verbosity ==
Well, it's verbose and we cannot have a lot of shortcut in the syntax, but
this way is clearly extensible and orthogonal


= C. Raised questions =
Where will we put the select attribute ? on p:input or on each of its child
?
What will be the consequence on verbosity of for-each ?


Of course, we can name these elements/attributes appropriately later.
> And we can use these same child elements on declare-[in|out]put.


I repeat my +1

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.



Just a couple of thoughts.
>
> Regards,
>
> Murray
>
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €