C++ and XML...
Kit Plummer
plug-devel@lists.PLUG.phoenix.az.us
Mon Jul 16 20:56:02 2001
On 17 Jul 2001 15:56:41 -0700, Rob Wehrli wrote:
> Kit Plummer wrote:
> >
> > The basic XML structure would look something like the following:
> >
> > <xml file>
> > ----------
> >
> > <?xml version="1.0"?>
> > <!-- preflight checklist prompts -->
> > <preflight>
> > <prompt>
> > <question>Aircraft Documents?</question>
> > <answer>Check</answer>
> > </prompt>
> > <prompt>
> > <question>Battery On?</question>
> > <answer>Check</answer>
> > </prompt>
> > <prompt>
> > <question>Flaps Down?</question>
> > <answer>Check</answer>
> > </prompt>
> > </preflight>
> >
> > ----------
> > <xml file>
> >
> > Granted this is an extremely stripped down checklist, but it would do in
> > the scheme of prototyping. Also, there would be another root structure
> > for other checklists like emergency.
>
> I wouldn't recommend this particular organization of elements. The
> reason why is obvious from a second set of eyes perspective. Notice how
> "prompt" and "question" and "answer" are all generic elements while
> "preflight" is a specific element "type." This suggests that you'll
> have a new element for "taxi" "takeoff" "landing" "weatheravoidance" and
> every other new checklist, which makes it hard to write a DTD! I'm sure
> that this is not what you meant to do, and simply used "preflight" for a
> placeholder.
This is true. There would a new element for each specific checklist.
> I wouldn't recommend stripping down the "checklist" any more than
> necessary to accommodate the requirements of the application. If the
> intent is to design a system that works with an endless series of Q&A
> with perhaps branching included, well, we don't need all this fanciness
> for that. A simple text file with a separator between values should be
> enough to populate an array to run through during runtime. However, if
> the idea of introducing XML to the application is for some advanced
> functionality that the simple "CSV" or other text file won't give us,
> then we need to consider that functionality.
The original reasoning for implementing XML was that the Windoze
Text-To-Speech processor could read from XML. Although, the longterm
embedded nature of the project will lead us away from Windoze it is
probably necessary for allowing pilots to run a prototype. The thought
is that we could send them the self-installer and then they could run
the demo.
>
> Here is a mild rework of your original data file, with a few minor
> changes.
>
> <?xml version="1.0"?>
> <CoPilot>
> <CheckList Name="PREFLIGHT" Identity="00000001">
> <!-- Preflight checklist prompts -->
> <Challenge Value="Aircraft Documents?">
> <Response>Check</Response>
> </Challenge>
> <Challenge Value="Battery On?">
> <Response>Check</Response>
> </Challenge>
> <Challenge Value="Flaps Down?">
> <Response>Check</Response>
> </Challenge>
> </CheckList>
> <CheckList Name="TAXI" Identity="00000002">
> <!-- Taxi checklist prompts -->
> <Challenge Value="Aircraft Documents?">
> <Response>Check</Response>
> </Challenge>
> <Challenge Value="Battery On?">
> <Response>Check</Response>
> </Challenge>
> <Challenge Value="Flaps Down?">
> <Response>Check</Response>
> </Challenge>
> </CheckList>
> </CoPilot>
>
This make good sense. My example was oversimplified for the sake of
example...
> >
> > The menu structure to get to the various checklists would be hardcoded
> > rather than pulled from a file because it would be the same regardless
> > of aircraft.
>
> I'm not quite sure that I agree with this statement. I'm sure that a
> 777 has a different set of "checklists" than a 152. The key to
> populating any menu structure would likely be to populate it through a
> parsing of the available XML data...IMHO. An appropriate "real-world"
> design for a checklist would have to take into account many factors for
> many different types of AC. For example, loading,
> wind/weather/temperature conditions, etc..etc. Are "Flaps Down"
> adequate for all situations? What percentage of flaps, is probably a
> more appropriate for a real world app.
I see what you are saying. NOTE: the focus from our standpoint is
general aviation and small plane owners - rather than commercial
aircraft and professional pilots. The point is that commercial aircraft
have a live "CoPilot" where a small plane owner often flies solo and
cockpit resource management is much more important.
Almost all aircraft have checklist for the same things (i.e. preflight,
which includes aircraft checkout, taxi, runup, and takeoff; climb;
cruise; descent; landing; and shutdown) That would be the reason for
eliminating the top-level elements. All checklist items are enumerative
in nature as well.
> Something like:
>
>
> <Challenge Name="Flaps" Value="20" Identity="10020100">
> <Response>Check</Response>
> </Challenge>
> <Challenge Name="Brakes" Value="100" Identity="10020101">
> <Response>Check</Response>
> </Challenge>
> <Challenge Name="Choke" Value="0" Identity="10020102">
> <Response>Check</Response>
> </Challenge>
> ....
>
> ...and, I believe that you won't be able to hard code all of these
> values in your XML, rather, you start with a series of "baselines" and
> then, based on programmatic interaction, you'll probably want to vary
> some of the values based on situational events.
>
> >
> > Anyway, what I think is to happen is:
> >
> > - The app is in a wait state, prompting for checklist name (preflight).
>
> Probably don't need to idle the app, just start it from invocation.
> Probably will find that we're going to be pointing the device driver at
> some start-up code that will parse the voice response and then fire some
> mapped application resource(s). The device driver will do what little
> is necessary to ensure basic data delivery then hand it off to the
> start-up app who then provides necessary decision support services and
> application invocation logic. There is no reason why we can't
> communicate to a running daemon using shared memory from the device
> driver, but it is probably a bit overkill for what we're talking about
> for a prototype, especially a prototype that doesn't need a device
> driver :)
>
Again, this is true considering the embedded nature. However, if we are
running an early demo on windows machines, then it might be different.
> >
> > - Once (preflight) is entered, the checklist is parsed and then cycled
> > sequentially until the hash is complete. NOTE: Future consideration
>
> I'd avoid the idea of "sequentially" as it tends to "force" us into
> thinking that our XML data file has all of the "answers" laid out in
> sequential order. While it may turn out to be a requirement that the
> data is properly organized in some manner, the "order" may not be
> sequential in terms of the file pointer and accessing it...especially in
> "branch conditionals." We may also find that there is a need for
> several XML files to properly account for exception handling and string
> responses.
>
> > will need to be given to the fact that it is possible for a negative
> > answer. In that case the given point in the checklist will need to be
> > marked in memory. I haven't thought about this much...
>
> If, by "negative answer" you mean adding exception handling that's
> true...otherwise, you'll need branching functionality for your
> conditionals...which is what I think you mean by "negative answer" :)
Yep. The pilot would need to enter a "go back menu" to go over failed
items and then "check" off.
> >
> > I am working on a formal DTD and XML files for each checklist. I should
> > be able to finalize something within the next couple of days. (I have to
> > teach class today and tomorrow.)
>
> I wouldn't think that more than one DTD would be needed for any number
> of CheckLists, which is what you may be saying above...but I don't see
> the need (except for some kind of simplicity?) for multiple
> checklist.xml files. If the idea is to parse a single file for a single
> checklist to help keep things simpler, that's fine, but don't do it for
> the "program" as it won't know the difference :) There is a situation
> where you might not want to parse the ENTIRE file given a lot of
> checklists, and that would be primarily when using a DOM parser. I'd
> still probably put all of the checklists into one large file--at least
> for "runtime"--and maintain separate files for development
> simplicity/keep our heads around it more easily.
I was thinking that it might be a good idea to have separate XML files
for each type of checklist. That way when and if we were to create the
checklist for new aircraft ... oh, I don't know. I suppose it makes
more sense to have all the aircraft's checklist in one file.
> >
> > Kit
> >
>
> Consider the above example then look below...
>
> <Challenge Name="Flaps" Value="20" Identity="10020100">
> <Response Valid="Check" Invalid="0x10200FEA"/>
> </Challenge>
>
>
> We can easily produce index mappings into object files with function
> entry points (given known signatures, or signature data) as a
> "post-processing" result of "building" our XML from "chained" XML data.
> Of course, we can simply use more "<Invalid></Invalid>" handling
> entities, if appropriate. Also, we can just as easily add <? target
> instruction ?> target instructions for special processing, such as even
> playing the appropriate .au file.
Our thought all along has been that we would use a Text-To-Speech engine
to speak out of the XML file - especially consider space requirements
for audio files in an embedded environment. But, considering TTS
quality and things like that it may make more sense to use .au files.
> Take Care.
>
> Rob!
> _______________________________________________
> PLUG-devel mailing list - PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>
Rob,
Your input has been greatly helpful and I truly appreciate it.
Cheers,
Kit