C++ and XML...

[Rob Wehrli]

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.

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.

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>


> 
> 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.

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 :)

> 
> - 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" :)

> 
> 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.

> 
> 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.

Take Care.

Rob!