W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > October 2008

RE: CGZ files

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 21 Oct 2008 08:59:42 -0600
Message-Id: <5.1.0.14.2.20081021083042.03375b88@localhost>
To: "WebCGM WG" <public-webcgm-wg@w3.org>

At 12:50 PM 10/20/2008 -0400, Weidenbrueck, Dieter wrote:
>[...]
>I agree with your analysis.
>
>One additional question:
>Would it make sense to establish cgz as an additional encoding (or
>something similar) to make it available to other profiles?

It is an interesting idea, and I hear that people would like to be able to 
do it.

"..establish as an additional encoding.." -- That approach would most 
sensibly involve working a corrigendum to CGM:1999 through ISO.  This would 
not be hard, process-wise.  But on the other hand, CGZ would be a somewhat 
different type of encoding than Binary Encoding or Clear Text 
Encoding.  (It is binary-encoded, then compressed as a whole -- not really 
the same sort of thing as the other encodings, IMHO.)

>I'm not
>thinking about WebCGM 1.0 per se, but other profiles building on ISO
>8632 might want to use zipping as well.

Yes, there does seem to be a use case, as I gather from you and from Don.


>I guess in general I find it a shame to restrict usage of zipping to
>WebCGM 2.1 only, and I would like to find a way to be able to use
>compression with any variant of CGM. Probably this could be declared as
>a kind of a storage/transportation variant outside of CGM?

We should be clear about the current situation.  It does not prohibit the 
use of CGZ compression for WebCGM 1.0 instances.  But it isn't supported it 
as a conformance scenario for 1.0 either, i.e., gzip-compressed CGM is not 
a conformance "Class of Product", and handling gzip-compressed CGM is not a 
requirement for the viewer "Class of Product".  (And 1.0 would in fact 
prohibit it, if it were claimed that the compressed instance is valid 
WebCGM 1.0).

What I mean is this... If "BE21" (BE10) is a valid WebCGM 2.1 (1.0) binary 
metafile, CGZ21 (CGZ10) is a gzip-encoded valid BE21 (BE10) metafile, V21 
(V10) is a conforming 2.1 (1.0) viewer, and Z is a standalone 
gzip-decompressor, then...

Valid WebCGM 2.1 scenario:  ...--> CGZ21 --> [V21]

Valid WebCGM 1.0 scenario:  ...-->CGZ10 ---> [Z] --> BE10 --> [V10]

That is, nothing prevents gzip compression of WebCGM 1.0 metafiles.  But it 
(CGZ10) has no standing as a valid content type for a V10 viewer according 
to the WebCGM 2.1 spec's conformance section.  (Note that the V21 viewer 
implicitly or logically integrates the process "Z", because of the 
conformance specifications of WebCGM 2.1).

This is kind of like what Dieter says -- that it is handled as part of the 
transport process, outside of the specifications of the WebCGM 1.0 
specification.

So ... where do we go from here?  Should we put something (informative) 
into 2.1, pointing out that the conforming 2.1 scenario can essentially be 
achieved also with 1.0 metafiles, except the compressed content CGZ10 is 
not a conforming 1.0 "class of product", and therefore must be decompressed 
into a valid BE10 metafile before it is a conforming input to a V10 viewer 
process?

Should we process errata for WebCGM 1.0 and WebCGM 2.0?  (Difficult, 
because can be argued as a substantive/technical change, and OASIS process 
prohibits such in Errata.)

Thoughts?

Cheers,
-Lofton.


>-----Original Message-----
>From: public-webcgm-wg-request@w3.org
>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>Sent: Montag, 20. Oktober 2008 12:06
>To: Bezaire, Benoit; WebCGM WG
>Subject: RE: CGZ files
>
>
>Benoit,
>
>Oops, my message crossed with yours.
>
>In short:  I agree that this is a conformance requirement for WebCGM
>2.1, specifically that 2.1 viewers must handle gzip-compressed 2.1
>instances, and that valid 2.1 instances included plain Binary Encoding
>as well as gzip-compressed instances of binary-encoded 2.1 metafiles.
>
>Long analysis:  see my other just-sent message.
>
>-Lofton.
>
>At 11:23 AM 10/20/2008 -0400, Bezaire, Benoit wrote:
>
> >I see your point, however...
> >
> >We have customers using WebCGM 1.0 "compliant" tools (IsoDraw/IsoView
> >v6 for example). Now, these customers could get a WebCGM 1.0 .cgz and
> >those "compliant" applications would reject them. That's not very
> >user-friendly.
> >
> >Maybe it's better to do this as a WebCGM 2.1 feature.
> >
> >Benoit.
> >
> >-----Original Message-----
> >From: Don L. [mailto:dlarson@cgmlarson.com]
> >Sent: Friday, October 17, 2008 6:59 PM
> >To: Bezaire, Benoit
> >Cc: WebCGM WG
> >Subject: re: CGZ files
> >
> >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 Tuesday, 21 October 2008 15:00:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 October 2008 15:00:47 GMT