Thoughts about the Defect Report

["Galt, Stuart A" <stuart.a.galt@boeing.com>]

Hello all,

I am not sure if this will help clear things up or make it worse...
It seems to me that there are three cases (that are not allowed by the 
current spec)

I tried to think of a state diagram that would describe the three
cases and identify what would be needed to implement the case. Please
forgive
me for my cheesy ascii drawing.  I put the states in () and the trigger
that causes the change are embedded in the ----> "arrows".  To simplify
my ascii drawings the ResText is just a text element that is not final
and
the TextFinal is an append text element that has text final set.


CASE1:  The application structure and the text do not overlap. 

In this case the application structure is entirely contained within
the text elements.

  --ResText-->(TOS)--BegAPS-->(SOS)--ENDAPS-->(TOS)--TextFinal-->...

The initial state would be either POS or SOS and the TextFinal would
pop the TOS off the "state stack" and the ending state would be the same
as the initial state.

To implement this option we need to add an "X" to allow AppendText
in the SOS state only if the previous text element that contains a
text tail set to not final.



CASE2: The application structure overlaps the beginning of the text.

For this one I had to define a new state that acts like a Text Open
State
(TOS) but when it is closed the SOS needs to be popped off the state
stack as well.  I will call this new minor state TOSC.

  --BegAPS-->(SOS)--ResText-->(TOS)--ENDAPS-->(TOSC)--TextFinal-->

The initial state for this case is either SOS or POS.  The TextFinal
that removes the TOSC state would need to also remove the TOS and SOS
off the stack as well.

To implement this case we need to add an "X" to allow ENDAPS in the 
TOS state, and we need to define a new minor state TOSC that behaves
similar to the TOS state.




CASE3: The application structure overlaps the end of the text.

For this one I had to define a new state that acts like a Structure Open
State (SOS) but when it is closed the TOS needs to be popped off the
state
stack as well.  I will call this new minor state TCSO.

--ResText-->(TOS)--BegAPS-->(SOS)--TextFinal-->(TCSO)--ENDAPS-->

The initial state of this case is SOS, POS, GSS, DSS, LSS.  For the 
purposes of webCGM I don't think we need to be worried about GSS, DSS
or LSS.  The ENDAPS that removes the TCSO state will also need to remove
the SOS and TOS from the stack.

To implement this case we would need to add an "X" to allow AppendText
in a SOS state, and we would need to define a new minor state TCSO.




I am now looking at Annex H to see if I can figure out how to express
these changes without being overly inclusive.  Does Annex H allow things
that are disallowed in other parts of the text?  Case one would be 
difficult to completely specify in Annex H.
 

--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656