Fwd: RE: Problem with WebCGM profile checking in MetaCheck

[Lofton Henderson <lofton@rockynet.com>]

All,

Rob Orosz and Peter Bono had a disagreement about MetaCheck diagnosis of 
some SF string limits in a 'linkuri'.

At the end of some analysis and dialog, copied below, there is agreement that:

-- CGM:1999 has some really muddled (confusing and incomplete) 
specifications in clause 9 and in the PPF.
-- WebCGM 1.0 perpetuated these, as did WebCGM 2.0

I think we have agreement that fixing it starts with a CGM:1999 defect 
correction.  Eventually then, we will make an erratum in W3C for WebCGM 
1.0, and an erratum in both W3C & OASIS for WebCGM 2.0.  Meanwhile, Peter 
Bono will fix MetaCheck to test for the *intended* rules.

We can try to get this second, simple defect report to Dick Puk by 
Friday.  I can have the text ready, I think.  If you care about this one, 
please read the dialog below and be prepared to give your opinions at the 
Wednesday AM telecon.

Regards,
-Lofton.

>From: Robert Orosz <roboro@auto-trol.com>
>To: "'Cruikshank, David W'" <david.w.cruikshank@boeing.com>,
>         "Peter R. Bono" <pbono@prba.com>, Lofton Henderson 
> <lofton@rockynet.com>
>Cc: Dieter Weidenbrueck <Dieter@isodraw.de>
>Subject: RE: Problem with WebCGM profile checking in MetaCheck
>Date: Tue, 5 Jun 2007 18:02:06 -0600
>[...]
>
>Dave,
>
>I think the term "Data record string" explicitly refers to elements that
>have "data record" parameters.  These include the all of the version 1
>elements with type D parameters and also, I assume, the version 4 element
>Application Structure Attribute, which has a parameter of type SDR called
>"data record."  As Lofton points out, type D "was replaced by the much
>better idea of SDR in V3."  In all of these cases, the parameter is called
>"data record" in the specification, and the elements that have these
>parameters are explicitly listed in section 9.5.4.7.
>
>I agree with Lofton that the simplest thing to do is stipulate that the
>rules for D and SDR are identical for total length, and for type SF embedded
>within.
>
>Regards,
>
>Rob
>
>-----Original Message-----
>From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
>Sent: Tuesday, June 05, 2007 3:11 PM
>To: Peter R. Bono; Lofton Henderson; Robert Orosz
>Cc: Dieter Weidenbrueck
>Subject: RE: Problem with WebCGM profile checking in MetaCheck
>
>
>The fact that the statement in T.14.6 "SDR-coding techniques must be
>used (see annex C.2.2)" for Data Record Strings tells me that when we
>said D, we meant SDF.  So my question is where would Data Record Srings
>occur outside of "non-graphical text strings"?  Need to fix it via
>defect.
>
>Thx...Dave
>
>
>Technical Fellow - Graphics/Digital Data Interchange
>Boeing Commercial Airplane
>206.544.3560, fax 206.662.3734
>david.w.cruikshank@boeing.com
>
>-----Original Message-----
>From: Peter R. Bono [mailto:pbono@prba.com]
>Sent: Tuesday, June 05, 2007 2:02 PM
>To: 'Lofton Henderson'; 'Robert Orosz'
>Cc: 'Dieter Weidenbrueck'; Cruikshank, David W
>Subject: RE: Problem with WebCGM profile checking in MetaCheck
>Importance: High
>
>Lofton et al.--
>
>I concur with your recommendations; namely, initiate a defect process
>for CGM that will affect WebCGM and, by the way, also S1000D.
>
>I can issue a new minor release to MetaCheck that uses the 1024 limit
>(the D
>limit) rather than the 254 limit (the standalone non-graphical string
>limit).  I do believe that was the intent (or at least "should have
>been"
>the intent).
>
>I will be away for three weeks starting Thursday morning, June 7.
>
>I will look for further emails at that time, change the code in
>MetaCheck (if everyone concurs), and then distribute a maintenance
>update to my customers on maintenance.
>
>Peter
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Tuesday, June 05, 2007 4:45 PM
>To: Robert Orosz; 'Peter R. Bono'
>Cc: Dieter Weidenbrueck; David Cruikshank
>Subject: RE: Problem with WebCGM profile checking in MetaCheck
>
>[...adding Dave to list...]
>
>Bottom line ... I think there are errors in CGM:1999 and these carry
>forward into WebCGM 2.0 (as well as 1.0), and they make it unclear what
>MetaCheck should do.  Summarizing:
>
>-- T.14.5 gives a rule (254) for type SF parameters.  I would argue that
>"standalone, not embedded" is implicit, because the next rule is...
>-- rule (1024) type SF within D
>
>But there is one other case of SF, and that is SF within SDR (embedded).
>I don't think the authors intended that to fall under the first rule of
>T.14.5.
>
>It is my belief that the authors intended that the cases of D and SDR be
>treated the same (as suggested by Peter), or explicitly be treated
>individually, as speculated by Rob in his comments about the three lists
>in 9.5.4.6.
>
>I would argue then that 9.5.4.6 should say either:  "...group of
>elements of type D or group of elements of type SDR which have type SF
>data [...embedded...]", or alternatively there should be three length
>numbers and there should be a third sub-paragraph "one for the group of
>elements...SDR..."
>
>Similarly, I think 9.5.4.7 should probably treat D and SDR synonymously
>(or explicitly call out separate limits).  Recall that D only occurs in
>the V1 escape and external elements, and it was replaced by the much
>better idea of SDR in V3.  But V1 could not be rewritten. so the Rules
>for Profiles did require that D be coded as SDR in any valid profile.
>
>There is some in-specification justification for the MetaCheck test
>(254), but I think it is based on errors in the specification.  I
>believe 1024 was the intended number for the 3 sub-parameters of
>'linkuri', the URIs and related metadata.
>
>I know this ultimately is no help.  MetaCheck is testing what it best
>discerns in the specification, which we all think is wrong (or
>unintended).
>If *all* experts agree it's wrong, then in the short term MetaCheck
>could perhaps take the course of an "Alert", instead of a "Fail".
>
>As Rob may be aware if he's monitoring the TC's public email list, the
>WebCGM TC is submitting a Defect Report to SC24/WG6, about text
>sub-strings within APS.  We're discussing it tomorrow, and hope to have
>it in the Convenor's (Dick Puk) hands by Friday, for their July Tokyo
>F2F.
>
>If we have some corrections here, then they start with CGM:1999 defect
>corrections.  Then they would carry forward into WebCGM 2.0 (and WebCGM
>1.0) as errata.
>
>We could start the CGM:1999 defect process, if we could agree quickly on
>the changes to 9.5.4.6, 9.5.4.7, and T.14.6.  Can we?  The simplest of
>all would be to assume that the authors intended SDR to be the
>well-formatted, well-behaved modern replacement for D, and therefore the
>D and SDR rules ought to be identical -- for total length, and for "SF
>within..."
>
>Hope this helps.
>
>Regards,
>-Lofton.
>
>At 09:35 AM 6/5/2007 -0600, Robert Orosz wrote:
> >Peter,
> >
> >You've highlighted what I consider to be an ambiguity in section
> >9.5.4.6 of the CGM standard.  Under the Length paragraph, it mentions
>this:
> >
> >Profiles may specify two length numbers:
> >one for the group of elements with data type SF parameters; one for the
>
> >group of elements with data type D parameters which have type SF data
> >within the D parameters, in the case that the D parameter uses SDR
> >formatting and contain type SF data.
> >
> >However, later in the same section it groups elements into three
>categories!
> >
> >Type SF Parameters
> >SF data within D parameters
> >SF data within SDR parameters
> >
> >Which of the two length numbers applies to elements that are in the "SF
>
> >data within SDR parameters" category?  Or, was the original intention
> >to allow profiles to specify three length numbers?
> >
> >The classification of some of these elements is puzzling too.  For
> >example, the Font Properties element appears in the "Type SF
>Parameters"
>category.
> >However, its parameters are a list n[IX, I, SDR].  The SDR contains SF
> >data for certain standard property values, e.g. 4 (font family).
> >Shouldn't the Font Properties element appear in the "SF data within SDR
>parameters"
> >category instead of the "Type SF Parameters" category?
> >
> >The Application Structure Attribute element has two parameters,
> >application structure attribute type (SF), and data record (SDR).  It
> >is correctly listed under the "Type SF Parameters" category.  Should it
>
> >also be listed under the "SF data within SDR parameters" category
> >because of the data record parameter?
> >
> >If the intention of the standard is to allow a different length limit
> >for elements in the "SF data within SDR parameters" category, then
> >Application Structure Attribute should also be listed under the "SF
> >data within SDR parameters" category.  If, however, the intention was
> >not to allow a different length limit for this category of elements,
> >then shouldn't the Bitonal Tile and Tile elements simply be listed
> >under the "Type SF parameters" category (like Font Properties)?
> >
> >I have no idea what the authors of this section originally intended.
> >I'm looking forward to hearing what Lofton has to say.
> >
> >Best regards,
> >
> >Rob
> >
> >Rob Orosz
> >Senior Software Engineer
> >Auto-trol Technology
> >12500 North Washington Street
> >Denver, CO. 80241-2400
> >(303) 252-2262
> >http://www.auto-trol.com
> >
> >-----Original Message-----
> >From: Peter R. Bono [mailto:pbono@prba.com]
> >Sent: Monday, June 04, 2007 8:01 PM
> >To: 'Robert Orosz'
> >Cc: 'Lofton Henderson'; Dieter Weidenbrueck
> >Subject: RE: Problem with WebCGM profile checking in MetaCheck
> >Importance: High
> >
> >
> >Rob--
> >
> >By this email, I'm inviting Lofton Henderson and Dieter Weidenbrueck to
>
> >give their opinions/interpretations.
> >
> >While I see your justification for 32767 as being the upper limit on
> >the sum of the lengths of these three linkuri string parameters, the
> >WebCGM profile states that these three parameters are of type SF
> >(clause 3.2.2.3 of the WebCGM 2.0 profile) and later states that type
> >SF parameters may not exceed
> >254 characters.  The only exception is that SF parameters within a D
> >record may be up to 1024 characters--but the SDR in a Application
> >Structure Attribute element is not of type D.
> >
> >So, are these three parameters (link destination, link title, and
> >behavior) just "data record strings" subject to the 32767 limit or are
> >they "non-graphical text strings" -- Type SF -- subject to the 254
>limit?
> >
> > >From a practical point of view, I wish the "SF within type D"
> > >separate limit
> >had also included "SF within type SDR".  I can see where 254 might be a
>
> >bit small for a link destination while 32767 is awfully large!
> >
> >The current MetaCheck code indeed does take the view that the
> >"non-graphical text string" limit of 254 does apply to each of these
> >three
>parameters.
> >
> >Best regards, Peter
> >
> >Peter R. Bono, Ph.D.
> >President
> >CGM Technology Software
> >P.O. Box 705
> >Yarmouthport, MA 02675
> >phone: +1-508-375-9420
> >fax:   +1-508-375-9422
> >http://www.prba.com/cts.htm
> >
> >
> >
> >-----Original Message-----
> >From: Robert Orosz [mailto:roboro@auto-trol.com]
> >Sent: Thursday, January 18, 2007 12:37 PM
> >To: Peter Bono (E-mail)
> >Subject: Problem with WebCGM profile checking in MetaCheck
> >
> >Hello Peter,
> >
> >I stumbled onto this issue while investigating a problem for one of our
>
> >TI customers. MetaCheck reports a WebCGM profile violation when the
> >link destination in a linkuri APS attribute exceeds 254 characters. I
> >don't think this is a correct interpretation of the standard.
> >
> >Clause 9.5.4.6 stipulates that the APS attribute element is subject to
> >the length limit for elements with type SF parameters. The APSA
> >parameter with data type SF is the "application structure attribute
> >type" parameter. For WebCGM, T.14.5 says the limit is 254 characters.
> >In this case, the value is 'linkuri" which is well under the limit.
> >
> >Clause 9.5.4.7 requires that profiles specify a maximum string length
> >for a data record or specify that there is no limit. It states the
> >Application Structure Attribute element is subject to that rule. For
> >WebCGM, T.14.6 puts the limit at 32,767 bytes. In the case of the
> >linkuri APS attribute, this would refer to the total length of the link
>
> >destination, link title, and behavior strings. Yet, MetaCheck reports
> >an error when the link destination exceeds 254 characters.
> >
> >Attached is a CGM file with two linkuri APS attributes. The first has a
>
> >link destination containing 255 characters, and the second has a link
> >destination containing 254 characters. MetaCheck rejects the former and
>
> >accepts the latter.
> >
> >Regards,
> >
> >Rob
> >
> >Rob Orosz
> >Senior Software Engineer
> >Auto-trol Technology
> >12500 North Washington Street
> >Denver, CO. 80241-2400
> >(303) 252-2262
> >http://www.auto-trol.com
> >
> >  <<twouris.cgm>>