Fwd: RE: Problem with WebCGM profile checking in MetaCheck - Lofton Henderson - org.oasis-open.lists.cgmo-webcgm

1 message in org.oasis-open.lists.cgmo-webcgmFwd: RE: Problem with WebCGM profile ...

From	Sent On	Attachments
Lofton Henderson	Jun 5, 2007 5:18 pm

Subject:	Fwd: RE: Problem with WebCGM profile checking in MetaCheck
From:	Lofton Henderson (lof...@rockynet.com)
Date:	Jun 5, 2007 5:18:37 pm
List:	org.oasis-open.lists.cgmo-webcgm

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 <rob...@auto-trol.com>

To: "'Cruikshank, David W'" <davi...@boeing.com>, "Peter R. Bono" <pbo...@prba.com>, Lofton Henderson <lof...@rockynet.com> Cc: Dieter Weidenbrueck <Die...@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,

-----Original Message----- From: Cruikshank, David W [mailto:davi...@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

-----Original Message----- From: Peter R. Bono [mailto:pbo...@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.

-----Original Message----- From: Lofton Henderson [mailto:lof...@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,

-----Original Message----- From: Peter R. Bono [mailto:pbo...@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:rob...@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,

<<twouris.cgm>>

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets