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: RE: [cgmo-webcgm] questions about the Defect Report


All,

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. To simplify the state table this restriction could be defined in the
Web2.1 profile.

Regards,
Forrest  

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Tuesday, May 29, 2007 6:36 PM
To: cgmo-webcgm@lists.oasis-open.org
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.






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