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: Dan Brickley <danbri@w3.org>
Date: Sat, 16 Mar 2002 11:59:06 -0500 (EST)
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>
Message-ID: <Pine.LNX.4.30.0203161149100.18236-100000@tux.w3.org>
On Sat, 16 Mar 2002, Martin Gudgin wrote:

> ----- Original Message -----
> From: "Dan Brickley" <danbri@w3.org>
> > On Fri, 15 Mar 2002, Martin Gudgin wrote:

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

OK, I had a crack at turning this into N-Triples so I could feed it to the
GraphViz visualisation tool. See
http://www.w3.org/2001/12/rubyrdf/examples/gudge/intro.html for N-Triples,
.dot, SVG and PNG versions.

Here's the N-Triples version. It differs only slightly from the syntax
we've used here, by distinguishing (_:foo vs <foo>) between URI-labelled
nodes and edges versions local identifiers.

_:nontermA <http://example.com/s#edgeB> "terminalB" .
_:nontermA <http://example.com/s#edgeC> "terminalC" .
_:nontermA <http://example.com/s#edgeD> _:nontermD .
_:nontermD <http://example.com/s#structE> _:nontermE .
_:nontermE <http://example.com/s#edgeF> "terminalF" .
_:nontermE <http://example.com/s#edgeG> "terminalG" .


> More comments on your mail as I have time,

thanks, look forward to it.

Here's a question: does the N-Triples data file above
contain everything that matters from the original SOAP Encoding, as far as
the SOAP Encoding Data Model is concerned? If not, what's missing? (order?
xml:lang language tagging?)

> Gudge

Dan
Received on Saturday, 16 March 2002 12:00:11 GMT

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