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.
