Questions and next steps - sjdayday/xschema GitHub Wiki

home or [back](Pass parameters)

Questions

  1. Are these functions sufficient to do useful work?
    Malte and I think this is a workable beginning; we'll see how it goes when we try to do real work.
  2. How soon do we need the x-schema project?
    I will be building x-schemas for my dissertation. Initially, I will build them by hand as in the code example. My guess is that will be sufficient for my purposes. Malte has said he will work along the lines in the code example. We'll see how far that goes; it may become unworkably complex, which would be a motivation to start sooner on the project.
  3. How much work is this?
    Some functions could be implemented without too much effort. "Merge arcs" (using merge places to link two x-schemas) seems like a small and useful extension to PIPECore itself. Bare-bones implementations of expanding a single transition, expanding the ongoing process, and adding optional standard semantics would not take too long. Making them robust won't be trivial, however, as the error detection and corner cases will likely take significant time. Guess: 6 weeks to get to an alpha release, plus or minus 2 weeks.
  4. How urgent is multi-threading?
    The PetriNetRunner in PIPECore is single-threaded. There is no reason a client cannot start multiple runners, each with its own Petri net, but I haven't thought through what would happen if multiple clients need access to the same Petri net, or a client needs to continue executing while the Petri net is running.
  5. What about a user interface?
    I've given no thought to what an x-schema UI would look like. I've not yet started updating the existing PIPE GUI to handle the new functions in PIPECore. Malte has some ideas about a simple way to depict executable Petri nets, which would be very useful.
  6. "x-schema" or "x-net"?
  7. Can the standard semantics really be optional?
    Our approach was to make only the basic control required (from Enabled to Done), and allow all the other semantics to be added as needed for a given x-schema. We preferred this to the alternative of always defining all the places and transitions of the entire semantics for every x-schema, for several reasons:
  • Defining everything every time seems too heavyweight.
  • Having all states for every x-schema seems to imply that each state might make sense for every x-schema, which is probably not realistic.
  • Defining all the standard states and transitions is not sufficient to have a well-behaved x-schema, as additional places would have to be added to trigger each transition only under appropriate conditions.

Next steps

  • Feedback would be useful.
  • Malte will try to follow the code example to see if he can make useful progress implementing x-schemas just using existing PIPEcore capabilities. His experience should identify gaps in the approach.
  • First pass at the code, based on the code example, and Malte's experience. Not sure when I'll get to this.

home or [back](Pass parameters)