OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]