W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Rework on SOAP 1.2 Part 2: Section 2 and 3

From: Martin Gudgin <marting@develop.com>
Date: Sat, 16 Mar 2002 16:14:06 -0000
Message-ID: <005601c1cd05$9a982f80$b47ba8c0@zerogravitas>
To: "Dan Brickley" <danbri@w3.org>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>, "XML Protocol Discussion" <xml-dist-app@w3.org>, <em@w3.org>

----- Original Message -----
From: "Dan Brickley" <danbri@w3.org>
To: "Martin Gudgin" <marting@develop.com>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>; "Noah Mendelsohn"
<noah_mendelsohn@us.ibm.com>; "XML Protocol Discussion"
<xml-dist-app@w3.org>; <em@w3.org>
Sent: Saturday, March 16, 2002 12:04 PM
Subject: Re: Rework on SOAP 1.2 Part 2: Section 2 and 3


>
>
> On Fri, 15 Mar 2002, Martin Gudgin wrote:
>
>
> Hi
>
> I'm not responding to the substance of this message, only its form. It
> reminds me of the way we used to conduct discussions in the old RDF
> groups, spending many happy hours creating ASCII-art representations of
> intricate graph structures. More recently we've adopted a different
> approach (see below).

Thanks for the input, it's very useful

>
> Also I just wanted to say that the proposed reworking of the data model
> text is (to my eyes) a big improvement.

Glad you like it

> (I didn't previously realise that
> edge order was always significant, for example. More or which briefly
below.)
>
> Anyway, re the ASCII art...
>
> > Per the encoding rules your second example ( relabeled );
> >
> > <structA>
> >   <edgeB>terminalB</edgeB>
> >   <edgeC>terminalC</edgeC>
> >   <edgeD>
> >     <structE>
> >       <edgeF>terminalF</edgeF>
> >       <edgeG>terminalG</edgeG>
> >     </structE>
> >   </edgeD>
> > </structA>
> >
> > the resulting graph would look like this ( per the encoding rules
> > described );
> >
> >
> >        edgeB +-----------+
> >      +------>+"terminalB"|
> >      |       +-----------+
> >      |
> > +----+-----+ edgeC +-----------+
> > |"nontermA"+------>+"terminalC"|
> > +----+-----+       +-----------+
> >      |
> >      | edgeD +----------+ structE +----------+ edgeF +-----------+
> >      +------>+"nontermD"+-------->+"nontermE"+------>+"terminalF"|
> >              +----------+         +----+-----+       +-----------+
> >                                        |
> >                                        | edgeF +-----------+
> >                                        +------>+"terminalE"|
> >                                                +-----------+
>
> (I don't quite follow the detail example, since I don't see where
> TerminalE and nonTermD come from, but going from the XML above...)

nonTermD is the node represented by element edgeD ( note this element also
represents edgeD ). TerminalE is a type, sorry. Should read terminalG and
the label should be edgeG ( that'll teach me to try and build ASCII art when
I'm tired! )


>
> If we wanted to avoid having to exchange loads of ASCII art, the basic
> (source node, edge, target node) triples from the example above might
> could also be represented with something like:
>
> nontermA edgeB "terminalB"
> nontermA edgeC "terminalC"
> nontermA edgeD structE
> structE edgeF terminalF
> structE edgeF terminal
>
> ...ie we flatten the graph into its constituent node/edge/node triples

Using your triples the graph would look like this;

nontermA edgeB "terminalB"
nontermA edgeC "terminalC"
nontermA edgeD "nontermD"
nontermD structE "nontermE"
nontermE edgeF "terminalF"
nontermE edgeG "terminalG"

More comments on your mail as I have time,

Gudge
Received on Saturday, 16 March 2002 11:13:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT