RE: [cgmo-webcgm] questions about the Defect Report

Yes, all 3 cases are required....I was just having trouble 
visualizing  things without nesting them.  I think of these APS in 
terms of para type APS (although they don't have to be), so substrings 
conceptually are part of a larger structure.

 

Dave

 

Technical Fellow - Graphics/Digital 
Data Interchange 
Boeing Commercial Airplane 
206.544.3560, fax 206.662.3734 
 

 

From: Lofton Henderson 
[mailto:] 
Sent: Thursday, May 31, 2007 2:57 
PM
To: Cruikshank, David W; 

Subject: RE: [cgmo-webcgm] questions 
about the Defect Report

At 02:35 PM 5/31/2007 -0700, Cruikshank, David W wrote:

I have to admit, I got a little confused reading through the cases 
  Lofton listed below.  
Summary:  my 6 examples 
illustrate these cases of substring tagging.

1.) tag a substring that 
occurs at the beginning of the whole string;
2.) tag a substring in the 
middle
3.) tag a substring at the end

These three cases must be 
handled, right?

In my mind the most common case (stripped of extraneous graphical 
  primitives) wold be:
 
<bas> RT(notfin) <bas> RT(fin) </bas> 
  </bas>
Did you mean AT(fin) instead of 
RT(fin)?  Okay, that is #3 above.  Are you saying that #1 and #2 are 
not required? 

I think the bracketing <bas>...</bas> around 
the whole mess is extraneous.  It could either be there or not, 
right?  I.e., it isn't required in order to tag (APS-ify) the substring, 
right?  As a matter of practice, it likely would be there.  (Or am I 
missing something?)

I guess that's captured in a general sense in Lofton's examples.  
  In this case, though the  state becomes more clear, I 
think.
I think there is still a small 
problem.   Suppose we fix the state table so that <bas> is 
allowed in TOS.  CGM:1999 says that Append Text can only occur in 
TOS.  What is the state when that AT element occurs (hint:  
SOS)?

<bas> RT(notfin) <bas> AT(fin) </bas> 
</bas>

I have been assuming that #1, #2, #3 above are all 
required.  Accordingly, I'm going to send another message with an idea that 
supports those three, and has the potential of being more cleanly 
specifiable.

-Lofton.

Technical Fellow - Graphics/Digital Data Interchange 
Boeing Commercial Airplane 
206.544.3560, fax 206.662.3734 
 
 

  
  From: Lofton Henderson [mailto:] 
Sent: Wednesday, 
  May 30, 2007 3:05 PM
To: 
  
Subject: RE: [cgmo-webcgm] 
  questions about the Defect Report

Thanks for the feedback 
  Forrest.

I have been doing some more detailed technical stewing over 
  this.  I suggest everyone have a careful read & think.  This 
  might be a topic for next Wed telecon.

At 08:53 AM 5/30/2007 -0500, 
  Forrest Carpenter wrote:

  [...]
I agree with Lofton, a 
    bas should only be allowed within not-final text if
the eas is contained 
    within the not-final text or immediately following the
final text. An eas 
    should only be allowed within not-final text if the bas
is within the 
    not-final text or immediately preceding the RT that begins the
text. 
  
We all have a clear notion of what we want to achieve -- to 
  simply APS-tag a partial text string, subject to restrictions like those, with 
  no "other-graphical-stuff" allowed within the defined APS.

  To simplify the state table this 
    restriction could be defined in the
Web2.1 profile.
Here is 
  what I'm struggling with.  Altho' we can define the concept very simply 
  and directly (with words, at least), in order for it to fly within SC24 as a 
  defect correction, I suspect that we will need to define it precisely in terms 
  of CGM:1999's formalisms:  the normative State Model (sec.6, tbl.8), and 
  the normative EBNF of annex H.

Here is what I'm struggling with 
  now.  I took the six examples that we agree are desirable, that have 
  strong use-case support, and that should have been allowed in CGM:1999 
  (V4).   Below I changed <eas> to </bas>, for clearer 
  illustration.  

Below each progression, I tried to identify the 
  state transitions that occur after each element.  There are places where 
  I just can't figure out what to do.  For example...

AT(notfin) can 
  only occur in TOS, and doesn't cause a state transition.  And 
  </bas> would be expected to "pop" the state that was in effect at 
  <bas>.  See below examples.  (You need to look at the 
  following in mono-spaced type, which is how I have formatted 
  it.)

..<bas> RT(notfin) ... AT(notfin) ... AT(fin) 
  </bas>......
.pos...|...sos....|.tos......................|.sos..|.pos.

..<bas> 
  RT(notfin) ... </bas> AT(notfin) ... AT(fin) 
  
.pos...|.sos......|.tos......|.???......|.tos.......|.pos.

..<bas> 
  RT(notfin) ... AT(notfin) <eas> ... AT(fin) 
  
.pos...|.sos......|.tos..........|.tos.|.???.......|.pos.

..RT(notfin) 
  ... <bas> AT(notfin) </bas> ... AT(fin) 
  
...pos......|.tos.....|.sos......|.???..|.???.......|.pos.

..RT(notfin) 
  ... <bas> AT(notfin) ... AT(fin) </bas> 
  
...pos......|.tos.....|.sos......|.???..|.???.......|.pos.

..RT(notfin) 
  ... AT(notfin) ... <bas> AT(fin) 
  <eas>
...pos......|.tos..........|.tos.....|.sos...|.???.|.???.

We're 
  facing the problem that, conceptually, we have sequences such 
  as:

<bas> <RT> </bas> </RT>

This in turn 
  could be seen as deriving from the fact that V1 CGM defined things like RT and 
  AT in an awkward, non-OO way.  What it really should have done (in 
  1987?!) is define a proper Compound Text 
  structure:

<begin-Compound-Text  (x,y) 
  (extent)>
   ...
  <text-fragment 
  (string)>
      
  <allowable-text-attr>*
  <text-fragment 
  (string)>
      
  <allowable-text-attr>*
  ...
  <text-fragment 
  (string)>
<end-Compound-Text>

If it were so defined, then 
  all of the partial-text tagging could be cleanly defined (and the state model 
  rules easily written down), e.g....

<begin-Compound-Text  (x,y) 
  extent>
  ...
  <BAS>
    
  <text-fragment>
        
  <allowable-text-attrs>
  </BAS>
  
  ...
<end-Compound-Text>

It is a vexing problem -- how to 
  express what we know should happen (that we can easily described with words) 
  in the formalisms of the ISO CGM document.  But IMO we must sort it out, 
  if we are to succeed with a SC24 defect correction.

I think we will 
  have better luck with the EBNF formalism (even tho' we still have to resolve 
  the State Model conundrum).  Currently the EBNF 
  says...

<BAS>  <picture element>* 
  </BAS>

This could become...

<BAS>  <picture 
  element>*  | <partial-text-element>  
  </BAS>

and then we could proceed like 
  this...

<partial-text-element> ::= <initial> | 
  <middle> | <terminal>
<initial> ::= <introducer> 
  <not-final-fragment>+
<middle> ::= 
  <not-final-fragment>+
<terminal> ::= 
  <not-final-fragment>* <final-fragment>
...etc...etc...

I 
  think we can continue to refine that down to acceptable terminal productions, 
  well defined, etc.  (Altho' I haven't done it yet.)

Anyone have 
  thoughts or contributions on this, or ideas how to deal with it?  Is an 
  ISO defect correction (for partial-text tagging) actually going to be our best 
  strategy to get the functionality into 2.1?

(Btw ... playing devil's 
  advocate, I could also imagine ISO folks asking, "...why not also allow 
  partial-closed-figure tagging, and partial-tile-array tagging?"  
  Answer:  we have no strong use case like partial-text 
  tagging.)

Regards,
-Lofton.

  -----Original 
    Message-----
From: Lofton Henderson [mailto:] 
Sent: Tuesday, May 29, 
    2007 6:36 PM
To: 
Subject: 
    [cgmo-webcgm] questions about the Defect Report

WebCGM 
    TC,

Okay, here are some gritty technical details and issues about the 
    potential 
Defect Report for partial-text/APS.  Feedback 
    invited.

Preliminarily, part 1 of CGM:1999 will be affected in these 
    places:

** State Table, table 8, beginning on p.104
** Annex H, 
    formal grammar of v4 metafiles
** (maybe) 7.6.4 - 7.6.6, descriptions of 
    Text, RT, AT

Let me note that there is already an error in Table 8, 
    p.105:  Append Text 
is not allowed in SOS.  So according to 
    that error..

legal:  <bas>  RT (final)  
    <eas>
illegal:  <bas>  RT (notfinal) ... AT (final) 
    <eas>

[Notation:  <bas> is Begin APS Structure, 
    <eas> is End APS Structure, RT is 
Restricted Text element, 
    etc]

That was certainly unintended.

It looks like it could be 
    tedious to work Table 8 and Annex H to say 
exactly what we wanted.  
    First we have to specify exactly what we wanted...

Conceptually, the 
    following cases clearly should be legal (as well as 
similar ones 
    substituting Text instead of RT) in V4 CGM:1999.  I.e., the 
    
valuable use case that V4 unintentionally threw out is to allow an 
    
"attributed partial text string" to be an Application 
    Structure.

<bas>  RT(notfinal) ... AT(notfinal) ... 
    AT(final) <eas>
<bas>  RT(notfinal) ... <eas> 
    AT(notfinal) ... AT(final)
<bas>  RT(notfinal) ... 
    AT(notfinal) <eas> ... AT(final)
RT(notfinal) ... <bas> 
    AT(notfinal) <eas> ... AT(final)
RT(notfinal) ... <bas> 
    AT(notfinal)  ... AT(final) <eas>
RT(notfinal) ... 
    AT(notfinal)  ... <bas> AT(final) <eas>

What about 
    cases like the following?

<bas>  
    [some-other-graphical-stuff]  ... RT(notfinal) ... <eas> 
    
AT(notfinal) ... AT(final)
(or)
RT(notfinal) ... <bas> 
    AT(notfinal)  ... AT(final) ... 
[some-other-graphical-stuff] 
    <eas>

It is my sense that these are ugly without commensurate 
    value.  So should 
they be excluded?

Making explicit the 
    inclusion/exclusion of those ugly cases is what will 
make it tedious to 
    detail the fixes to Annex H, especially.  I think the 
fixes will be 
    easier to specify cleanly if we *exclude* the ugly 
    cases.

Thoughts?

Regards,
-Lofton.