W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2006

Re: Alternative to x!y (proposal)

From: Innovimax SARL <innovimax@gmail.com>
Date: Sat, 26 Aug 2006 10:11:05 +0200
Message-ID: <546c6c1c0608260111t47499d3coa6b3a71d2d7fa1c3@mail.gmail.com>
To: "Murray Maloney" <murray@muzmo.com>
Cc: public-xml-processing-model-wg@w3.org

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

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

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

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


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
    <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:documentation> Extra documentation for the second element of the
sequence </p:documentation>
    <my:output-debug-on-reach>We are in the middle of the

As pointed out by Murray, I don't care with the name, only the concepts are
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
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Saturday, 26 August 2006 08:13:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:40 UTC