UPD Mail Archive: UPD> the philosophy about command sequences

UPD Mail Archive: UPD> the philosophy about command sequences

UPD> the philosophy about command sequences

From: Norbert Schade (norbertschade@mediaone.net)
Date: Tue Feb 12 2002 - 16:30:14 EST

  • Next message: Norbert Schade: "UPD> web site update"

    In L.A. we agreed on a redesign of command sequences and parameter handling.
    While we still are dedicated to the earlier directive to keep the real command sequences and parameters out of the technical device description and gather it in a separate file.

    But over the time we learnt that we cannot predict the number of parameters needed in every case. Predefine them as ComSeq_Parameter_1, ..._2, etc. was not the optimum solution either.

    Secondly we are facing features (e.g. Raster grahpic), which require dealing with more than one command sequence. Predefined element names don't look promising here neither.

    A third argument was brought in that the management of command sequences is inconsistent, as sometimes driven by features, sometimes by events.

    Ok, that was valuable feedback. And we worked it over.

    Now the management of command sequences is strictly initiated by events. The events describe the print stream and therefore refer to command sequences at the proper place.
    If no parameters are needed (like an init: <esc> E), the reference can be resolved in the command sequence xml file. The corresponding schema is now split into two sections: CommandSequences and Parameters. Both sections can have a practically indefinte number of elements CommandSequence_ID respectively Parameter_ID. As there must be exactly one leading element per schema, we define one: Commands. This one has the two sections underneath.
    If parameters are needed, they can be referred to within a command sequence, where you can point to a feature. This feature will have to provide a Command element with an attribute CommandSequence_ID, which will show exactly the same reference as originally in the event and serves as an identfier for the correct command sequence, and another attribute Parameter_ID, which is resolved in the Parameters section. This way we can easily manage more than one Command element, as we can identify them.

    See the schema and samples flying in tomorrow. I'm working on that right now.

    Norbert Schade
    69 Prescott Drive
    North Chelmsford, MA 01863

    This archive was generated by hypermail 2b29 : Tue Feb 12 2002 - 16:31:05 EST