| Re: Branches and connections - a neverending story [message #82 is a reply to message #81] |
Mon, 14 June 2004 10:03  |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
Matthias Hengartner wrote:
> We decided to remove the <singleCrossOver>-element, because it would raise
> unnecessary work for importing applications. So <switch> will be the only
> child element of <connections> for the present. Of course we could discuss
> about the sense and the naming of this <connections>-container.
Fine! I totally agree with you that <singleCrossOver> caused only
confusion and overhead.
> Here a simple example (I removed attributes which are not relevant for this
> topic and added the attribute "trackType" to show roughly what we mean).
>
> [....]
>
> As you can see, we have an additional third track for the crossover.
>
Yes, this structure is much easier to understand and to implement.
And it is closer to reality: a switch is a <switch> and a track is a
<track>. So far, so good.
But this way of describing the infrastructure is very close to a
vertex-edge-graph and if I remember correctly, a
vertex-egde-representation of the track was rejected in the early stage
of the development of the schema.
Just think of edges as <track> elements and nodes as
connectionID-attributes. The connections between nodes are made via
<branchConnection>, which effectively connects to vertices (the
connectionID of the parent element and its own branchIDRef).
So here is your example with "vertices" (o), their IDs and egdes (-----):
15 16
o---------------------------------------------o
\
o 20
25 o
\
\
o 26
21 o
\
o----------------------------------------------o
18 19
Personally, I like vertex-edge-representations and therefore I can live
with this structure without problems (the only tricky thing about this
graph is, that a switch has only ONE vertex and not three vertices like
in normal graphs).
Additionally, some attributes of <branchConnection> make no sense
anymore (e. g. branchDist, which is given by the track length).
And: Is <branchConnection> still neccessary if the branch is a separate
track? Perhaps the information which is now stored in <branchConnection>
can be merged into the parent element (either <switch> or
<simpleConnection>). As an alternative, we could think of a pure
<conenction>-element, which combines the functions of <branchConnection>
and <simpleConnection>; this is possible, since both elements now just
connect to nodes. Or we can only use <simpleConnection> and remove
<branchConnection>, since effectively we only have connections between
<track>-elements which should originally be handled by
<simpleConnection>. Or.....
So these are my suggestions for today... don't kill me if they are too
blasphemic... ;)
Best regards,
Volker
|
|
|
|
Members
Search
Help
Login
Home
