W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > August 2007

Re: Comments on the 1.0 errata scan

From: Lofton Henderson <lofton@rockynet.com>
Date: Thu, 16 Aug 2007 17:46:35 -0600
Message-Id: <5.1.0.14.2.20070816155812.0384d470@localhost>
To: WebCGM WG <public-webcgm-wg@w3.org>

WebCGM WG,

Some initial replies to Rob's 1.0 errata comments...

At 03:06 PM 8/16/2007 -0600, Lofton Henderson wrote:

>Hi WebCGM WG,
>
>I got the following public (non-member) comments about my collection of 
>proposed 1.0 errata [1].
>
>[1] http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0001.html
>
>[...]
>>From: Robert Orosz <roboro@auto-trol.com>
>>To: 'Lofton Henderson' <lofton@rockynet.com>
>>Subject: RE: [cgmo-webcgm] Fwd: results of 1.0 errata scan
>>Date: Tue, 14 Aug 2007 10:37:45 -0600
>>[...]
>>Lofton,
>>
>>Thanks for explanation about keeping WebCGM 1.0 around.  It's a very
>>subtle point IMO, but it does make sense.
>>
>>I have a couple of comments regarding the errata.  First, an error on the
>>W3C errata page itself.  Near the top right after "This document records
>>known errors ..." it says "Latest WebCGM 2.0 version:"
>>
>>Shouldn't that be "Latest WebCGM 1.0 version:"?

Yes.


>>I'm curious about E03.  Is the erratum simply due to the lack of an example?
>>Or is there more to it than that?

As I recall, we all agreed that it was inappropriate that 1.0 presented 
possible search algorithms in such a way as to suggest that they were 
normative 1.0 viewer behavior [2].  Therefore 2.0 removed these from the 
normative text section [3] and made it explicit that they were EXAMPLES of 
how one might build application-dependent search protocols on the 
standardize APS and ApsAttr elements.

[2] http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_2_1_3
[3] 
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-IC.html#webcgm_3_2_1_3


>>Regarding Item #2 in your errata scan, I'm not convinced that the authors of
>>the model profile meant to say "128 graphical primitive elements."  The
>>rest of the standard and model profile are very consistent about using the
>>state tables (Tables 8a and 8b) to specify the content rules for "aggregate"
>>structures, and the Model Profile simply limits the number of eligible
>>elements
>>in each structure.  For example, compare with T.15.6 and T.15.7.
>>
>>WebCGM is of course free to change the model profile spec for figures.  The
>>issue of course is how to word it.  If the statement is changed on the
>>WebCGM
>>side to "128 graphical primitive elements", that might be interpreted to
>>mean
>>that attribute elements aren't allowed at all in a closed figure.  Is that
>>what is intended?  An alternative solution would be to increase the number
>>to 1024 (which aligns it with 2.0) and leave it at that.

This is purely my opinion, but I suspect that the original intention was 
"number of graphical primitive elements is limited to 128, with no 
restriction on associated attribute and control elements."

But basically I don't feel strongly about it.

Any thoughts?

(A Dave/Lynne dialog was the apparent source of this one, and Lynne seems 
to agree about "128 graphical primitives".)


>>Regarding Item #4, that clearly is an error in the Model Profile.  The fact
>>that the Model Profile column does have a Prohibited check box means that
>>profiles are allowed to prohibit the Application Data element.  So, the
>>statement immediately below the check boxes makes no sense.

Right, this is pretty much just an editorial goof in the MP.  Since we 
can't change the MP (it is the responsibility of SC24 to do that by defect 
correction), we can note in the profile that it is considered to be an error.


>>Items 2 and 4 reminded me that one of the big reasons for WebCGM 1.0, 2nd
>>release, was to align with the 2nd edition (1999) of the CGM standard.  One
>>of my WebCGM 2.0 review assignments was chapter 6.  When I reviewed it, I
>>quickly discovered that it was not based on the 2nd edition of the CGM
>>standard, but instead the original amendment to the 1st edition of the CGM
>>standard.  I assume that the WebCGM 1.0 2nd Release text was the starting
>>point for WebCGM 2.0, so this issue probably affects WebCGM 1.0.  Here's the
>>link to my email to jog your memory.
>>
>>http://lists.oasis-open.org/archives/cgmo-webcgm/200509/msg00136.html
>>
>>A lot of other early WebCGM 2.0 review comments probably apply to 1.0 as
>>well.
>>Since I was assuming that WebCGM 2.0 would replace 1.0, I wasn't really
>>paying
>>attention to the impact on WebCGM 1.0 of issues raised.  I might be worth
>>going back and looking at my (and others) review comments on WebCGM 2.0
>>drafts
>>to see if there are any comments that are relevant to WebCGM 1.0.  It
>>wouldn't
>>surprise me if there are some.

Ugh!  Yes, there were errors in the MP column of the 1.0 2nd 
Release.  That's the bad news.  The good news is ... spot checking the 
first 5 of Rob's many corrections (which *did* make it into 2.0 MP column), 
I found none that had substantive implications for the normative rules of 1.0.

I will finish scanning all of the old MP corrections and report back again.

I would propose -- if the identified MP bug has no normative implications 
for 1.0 implementations, then leave it.  Else fix it.  We could put a 
comment ahead of all the PPF tables, indicating that there are deviations 
of the WebCGM 1.0 MP column from the CGM:1999 MP column, but they have no 
normative implication in general (unless specifically corrected by an erratum).


>>Another WebCGM 2.0 issue that I am aware of that probably affects 1.0 came
>>up
>>during the end of preparing the test suite.  One of the tests in the static
>>portion of the test suite involved six degenerate elliptical arcs.  One of
>>them was an elliptical arc close element.  The reference PNG had the radius
>>drawn from the center point to the first CDP end point.  Somebody, (Don or
>>Forrest I think) objected, and after some discussion we all agreed that it
>>makes the most sense to draw the radius from the center point along the
>>degenerate start/end ray.  However, D.4.5.12 in the CGM standard simply says
>>"... a radius should also be drawn ..." without specifying any more detail
>>about the direction of the radius.  This is probably best handled by a
>>defect
>>report to SC24.  Since this was a static test, I'm assuming it was lifted
>>from the WebCGM 1.0 test suite, and therefore this applies to WebCGM 1.0.
>>I'm also assuming that the newer W3C process rules will apply to WebCGM 1.0
>>3rd Release, and the test suite will be more prominent than it was
>>previously.

Yes, I remember this one.  I'll go back and have a closer look, but I think 
Rob is right.  Unless someone remember differently, we should add it to the 
queue.  I would suggest to queue another CGM:1999 defect 
correction.  Meantime, in WebCGM 1.0 and 2.0 errata, we should point out 
the assumed "along the ray" condition.


>>That's all that I can think of for now.

Thanks to Rob for his contribution.

Regards,
-Lofton.
Received on Thursday, 16 August 2007 23:46:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:10 GMT