Re: [cgmo-webcgm] Thoughts about the Defect Report

[Lofton Henderson <lofton@rockynet.com>]

Thanks, Stuart, for a well-thought-out contribution.  Some comments about it...

Stuart's three cases are essentially the same as the three cases that I 
identified in an earlier thread:
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/email/archives/200705/msg00017.html

Like Stuart, I have concluded (but didn't express in my messages) that the 
beginning-fragment and ending-fragment cases essentially involve defining 
new states in the CGM:1999 State Model.  I also went down the road to look 
at necessary mods to the formal grammar, and came up with some ideas that 
should work:

In H.3.1, change the line defining the content of the APS body from
<picture element>*
to
<picture element>* | <partial text element>

Then in H.3.5, around the area of the <text element>, add code:
<partial text element> ::= <initial> | middle | <terminal>
<initial> ::= <introducer> <not-final-substring>+
<middle> ::= <not-final-substring>+
<terminal> ::= <not-final-substring>* <final-substring>
...etc...etc...etc...
<introducer> refines to the opcode, x,y, extent, etc.  The substring 
expressions refine in obvious ways.

That all seems simple enough, but here's what concerns me, especially with 
the State Model parts of the modifications.  Have a look at the defect 
materials that I just posted:
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/24228/defect-form-examples.zip

We need to choose a category:  error, omissions, etc.  We can debate about 
the right category, but I'm thinking that *minimality* of needed repairs to 
CGM:1999, in order to allow partial-text tagging, will make the prospects 
easier in SC24.  For example, try to put yourself in the mind-set of a 
critical reviewer who sees that we're fixing an "error", or an "omission", 
and the fix comes with a big pile of baggage on the State Model.

Maybe it would pass without comment.  Maybe it would raise concern.  I 
don't know the answer, but I'm just trying to anticipate *potential* 
difficulties.

"Minimality" was the motivation behind my alternate suggestion:
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/email/archives/200705/msg00018.html

Essentially, in the formal specification, I throw out Stuart's CASE2 and 
CASE3, allowing only CASE1 (formally, at least).  Then I show how CASE2 and 
CASE3 can be achieved within formal CASE1 constraints, by authoring 
cleverness.  The sleights-of-hand to achieve CASE2 and CASE3 are all 
legitimate, legal CGM V3 stuff.  (I checked the V3 grammar, and yes, it 
does allow the empty substrings.)

So with this approach, the only mods to the CGM:1999 State Model are 
Stuart's CASE1.  Then WebCGM 2.1 says that you shall support this, and you 
shall support CASE2 and CASE3 use cases by the indicated technique / 
application of CASE1.

It has the disadvantage that the material must be authored to achieve the 
effect.  E.g., you couldn't do my work-around with legacy material and the 
Overlay Model.  (But that is probably not useful here anyway.)  It also 
seems slightly ... ummm ... artificial?  (The right word escapes me.)

Any case, I think two options emerge now:
1.) support CASE1, 2, 3 directly with the modifications to CGM:1999 (State 
Model and Formal Grammar);
2.) support CASE1 directly in CGM:1999, and in WebCGM 2.1 mandate CASE2 and 
CASE3 by the indicated technique / application of CASE1.

Regards,
-Lofton.

At 03:25 PM 6/1/2007 -0700, Galt, Stuart A wrote:
>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