re: CGZ files

I think the best way to ask and answer Benoit's question is in terms of the 
conformance terminology of Ch.7:
[1] http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Conf.html

Specifically, what does gzip-compressed metafile ("CGZ") mean in the 
context of "class of product" of 7.1:
[2] 
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Conf.html#webcgm_conformance_CoP

My answer:

** it is a conformance requirement on viewers, that they MUST be able to 
interpret/view gzip-compressed metafiles;
** it is a conformance requirement on content (see T.13.1) [3] -- the 
metafile encoding MUST be Binary, and the binary-encoded WebCGM 2.1 
metafile MAY be gzip-compressed.  (Alternatively, the encoded metafile MUST 
be either CGM:1999 Binary encoded, or CGM:1999 binary encoded with GZIP 
compression.)

[3] 
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_2

Benoit asks:  "version 1 to 4"?  I think: well, why not?  Those are valid 
2.1 metafiles, and 2.1 doesn't otherwise restrict that only files with 
certain METAFILE VERSION values may be gzip compressed.

Benoit asks:  "Version 1.0"  (WebCGM ProfileEd:1.0)?  My thoughts:

1.) clearly, it would not be a valid WebCGM 1.0 instance (1.0 does not 
allow GZIP);  also, it would not be a valid 2.1 instance (the ProfileEd 
must be 2.1);  thus I disagree with Don's assertion (below) that viewers 
need to be able to handle a GZIP-compressed WebCGM 1.0 instances.  If we 
want this, then we are going to have to process a (substantive) 1.0 and 2.0 
erratum to allow it.

2.) this brings up the subtle question, "Does a valid WebCGM 1.0 metafile 
comprise a valid WebCGM 2.1 metafile?  (Or 2.0, for that matter.)  The 
answer is:  No.  You don't need to look any further than T.16.2, METAFILE 
DESCRIPTION (the requirement about the ProfileEd substring).  But also ... 
deprecation and obsoletion mean that there can be some things in a 2.0 
metafile that *must not* appear in valid 2.0 or 2.1 metafile instances.

Aside from the disagreement with Don about WebCGM 1.0 and WebCGM 2.0, I 
think his statement can be modified to capture what I believe is 
true:  "... a WebCGM 2.1 viewer MUST be able to open gzip-compressed 
metafile and MUST be able to view the result if the decompressed result is 
a valid WebCGM 2.1 Binary-encoded metafile."

But Don's reply contains something else that we should be careful 
about:  "should be able to open a file with a .cgz extension".  Note 
(section 2.4 [4]) that we have only *recommended* the .cgz 
extension.  Unless we want to change that, we should refer to 
gzip-compressed metafile, if we want to be precise (".cgz" might be okay as 
loose shorthand, as long as we understand what is really meant).

[4] 
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_2

Thoughts, anyone?

My QUESTION (all):  Is there a need for clarifying text somewhere?  (GZIP 
is mentioned in section 1.2, 2.4, and 6.2 [T.13.1]).

If your answer is "yes", please propose what and where.

Regards,
-Lofton.






At 05:56 PM 10/17/2008 -0500, Don L. wrote:

>Benoit
>
> >  Hi  All,
> >
> >  I find the draft  underspecified about compressed CGM files. More
> >  specifically, we would like to  know what kind of CGM files may be
> >  compressed?
> >
> >  Version1 to  4?
> >  Can I compress a  WebCGM 1.0 CGM file for example?
> >
> >  Is this a WebCGM 2.1  conformance feature for viewer and authoring tools?
> >  Or is this a new WebCGM  2.1 (and only 2.1) 'encoding scheme' ... for lack
> >  of a better  word?
>
>I think 'encoding scheme' is a better characterization. The text for this 
>feature
>in the webcgm 2.1 spec was extracted from the SVG spec.
>
>My thinking is that this is a viewer conformance issue and a WebCGM 2.1
>viewer should be able to open a file with a .cgz extension and know that it
>needa to decode this file according to the gzip spec. with the assumption 
>that
>results will be a file that conforms to the WebCGM profile (any version e.g.
>1.0 , 2.x).
>
>Don.
>
> >  Thanks.
> >  Benoit.

Received on Monday, 20 October 2008 16:03:58 UTC