RE: CGZ files

Possible discussion topic for Wednesday TC telecon...

Specifically for the benefit of TC-not-WG folks, I point out that the CGZ 
discussion has come alive again in the WG:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0009.html

To be clear ... the 2.1 ball is in the WG court now, and that is where 
active discussion and resolution will happen.  But if you are *not* in the 
WG, and if you care about this issue, then we can ensure that your 
perspective and opinions are included in the WG's resolution process.

As a routine matter, if you are not in the WG and care about its issue 
resolutions, I would recommend that you monitor the WG email archives 
regularly.  They are publicly readable:
http://lists.w3.org/Archives/Public/public-webcgm-wg/

We want to be sure that everyone is happy with any changes to the 2.1 spec 
*before* the spec comes back to OASIS.

Regards,
-Lofton.

p.s.  You will also see some W3C I18N comment processing starting in the WG 
archives, concerning some of the ACI stuff.


At 06:17 PM 10/21/2008 -0600, Lofton Henderson wrote:

>Good questions, Dieter.  I have some opinions (surprise!)...
>
>At 05:39 PM 10/21/2008 -0400, Weidenbrueck, Dieter wrote:
>>[...]Following your conclusions:
>>
>> >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?
>>
>>So that raises a question for me:
>>If we agree that zip compression is more like a "transport feature"
>>(like ftp compression btw), and if we agree that it is legal to zip a
>>1.0 file and decompress it before a v1.0 viewer can read it, then
>>Why do we add zip compression to WebCGM at all?
>
>I think the idea was to ensure that a 2.1 generator could safely gzip a 
>2.1 metafile, and be assured that all conforming 2.1 viewers would handle it.
>
>It was patterned after how SVG did it.
>
>>Why don't we define a
>>pure viewer feature like many others to handle zip compression?
>
>I'm not sure I understand this point.  For 2.1, I though we did 
>essentially place a conformance requirements on viewers, that they must be 
>able to handle gzip-compressed binary-encoded WebCGM instances.  What am I 
>missing here?
>
>
>>For example, we expect a viewer to download files from a server using
>>the usual protocols, however, that protocol (e.g. http) is not part of
>>WebCGM itself.
>
>Indeed.  And there are many other ways that the metafile can arrive at the 
>viewer.  (DVD, flash memory, etc.)
>
>>Could we possibly simply distinguish between viewers that support zipped
>>CGMs, no matter which version and profile, and viewers that don't?
>
>If I understand correctly ... this does not seem to be a good route to 
>widespread interoperability -- dividing the world into viewers "that can" 
>and viewers "that can't", on something we have already endorsed (for 2.1) 
>as useful.
>
>I.e., vendors A & B generate gzip regularly, and interpret it.  Vendor C 
>has a viewer that regularly receives .cgz from A & B.  But vendor D never 
>receives A & B metafiles, and so doesn't bother to implement .cgz.  Until 
>that day when ...etc...etc...
>
>I think that scenario potentially gives CGM a black eye -- "doesn't work."
>
>
>>Supporting the OBJECT tag of HTML is not a part of WebCGM at all, still
>>the viewer needs to support it.
>>
>>I guess I am not sure where to put this, perhaps somebody has a good
>>idea.
>
>We enumerated and endorsed the requirement some time ago (August 2007).  I 
>see it as useful, as do some others.  I'm satisfied to go forward with it 
>in 2.1, as a normative requirement in 2.1 on viewers.  It might not be 
>architecturally pure, and there are consistency questions like you raised 
>about OBJECT and HTTP.  (Although I personally consider them to be one 
>step further removed from encoded metafile content.)
>
>Plus ... we know that it will pass muster in W3C, since it is exactly what 
>SVG does about compression.
>
>So in short, I'm not inclined to reopen the requirement issue for 2.1.
>
>That said, there is a valid question what people want to do about 1.0 and 
>2.0, where it would be just as useful, but where it was not proposed in 
>time to be part of those base specifications.
>
>Regards,
>-Lofton.
>
>>-----Original Message-----
>>From: public-webcgm-wg-request@w3.org
>>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>>Sent: Dienstag, 21. Oktober 2008 11:00
>>To: WebCGM WG
>>Subject: RE: CGZ files
>>
>>
>>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, 11 November 2008 15:40:39 UTC