> > > A document is a file and can contain many networks (it's the equivalent of a .c) > > Then this is something like Loci's 'workspace' or 'workflow diagram', or > Jarl's 'dataflow structure'. Yes. > > This is a node definition. The name is arbitrary, > > The name is akin to Loci's identification number, which is really a URI to the > XML representation of the node. GMS uses dname : description name, or 'human readable name', and name : an id number. Every instance of gms gets a id number too, so the 'Loci URI' is equalavent to gms's 'instance id + name', a 64bit number. > > while the type corresponds to an Overflow node class. > > Great, this is just like Loci's locus types/classes. This is something gms wont touch, class 'types' wont exsist in this layer. They will simply be handled as a node and passed to overflow. > > x and y are for the GUI. > > I think for VSH we should have the GUI store that information. If we are to > have more than one interface available for VSH, x and y will not always be > relevant. This is what we were going to do with Loci. Seems logical. There's no need to store x\y into the processing layer. But it wont harm the GUI too, it can just ignore those values. Or is there a special reason to have them inside the nodes? > When I first came across Overflow (when you posted the announcement on > gnotices), I noted to Brad how remarkably similar some of its features are to > Loci's. This is particularly true for the XML representation of a network. > > This is something GMS (which uses no XML) needs to implement as well. And > since Overflow and Loci are so similar, we should choose one definition. Can > you comment on what you like or dislike about Loci's use of XML for network > representation? Let's hammer this out right away. OK, the overflow & loci people should define this definition. GMS will only use a few lines where the gui and overflow layer will use every single line. Make it whatever you see fits best.