revised CGZ proposal

All --

I'm going to propose a slightly different resolution than what is in the 
previous (below-attached) thread.  Approval of this change will be on the 
next WG telecon agenda (04-dec).

Part 1:  basic resolution
==========

Basically, to accommodate dissatisfaction with potential bending the 
CGM:1999 Rules for Profiles, we will instead make gzip support a Chapter 7 
viewer requirement, that WebCGM 2.1 viewers properly handle gzip-compressed 
Binary-encoded WebCGM 2.1 content.

The proposal:

1.) remove the "Other:..." gzip requirement from T.13.1 in Chapter 6;
2.) Add to the end of @@7.1:  "WebCGM 2.1 viewers, both static and dynamic, 
must correctly handle valid WebCGM 2.1 Binary-encoded metafiles that are 
gzip-compressed."

That, I believe, captures the sense of recent discussions.  Comments on 
that part of it?

Part 2:  a lurking question
===========

I will point out in advance that this revision leaves open a question about 
WebCGM 2.1 viewers and gzip'd 2.0 or 1.0 content.  If you look at Ch.7's 
deprecation and obsoletion wording, for example, you will see that we don't 
require that a conforming 2.1 viewer be a conforming 2.0 viewer (nor 
1.0).  But 2.1 viewers can optionally feature 2.0/1.0 conformance -- i.e., 
correct handling of 2.0 and 1.0 metafiles per the 2.0/1.0 conformance 
rules.  In fact, I would guess that almost all are built that way.

So the question:  do we want to apply the 2.1 viewer gzip requirements to 
older content (2.0/1.0), for those 2.1 viewers that claim backward 
compatibility for 2.0/1.0?  I.e., something like "In addition, 2.1 viewers 
that correctly handle valid 2.0 or 1.0 content per the conformance 
requirements of those (2.0 or 1.0) WebCGM versions shall correctly handle 
such metafiles when they are gzip compressed."

Please comment on that refinement, pro or con.  What do people want?

(In parallel, Lofton has an action item to contact Dick Puk at SC24 about 
processing a corrigendum or addendum to ISO 8632, that would add 
gzip-compressed Binary, at least, to the valid encoding/content types of 
ISO 8632).

-Lofton.

At 02:54 PM 11/12/2008 -0800, David Cruikshank wrote:
>I like this solution.  As long as I'm using a 2.1 viewer, it doesn't 
>prevent me from using zipped cgm files in my database of graphics.
>
>Dave
>
>On Wed, Nov 12, 2008 at 12:13 PM, Lofton Henderson 
><<mailto:lofton@rockynet.com>lofton@rockynet.com> wrote:
>>All --
>>
>>Having read preferences and concerns in this thread, and following on 
>>from the discussion that happened this morning in the TC's telecon, IMHO 
>>this is the right way to handle the CGZ questions that Benoit raised...
>>
>>1.) completely clarify in 2.1 text that gzip'd binary CGM (content) is a 
>>valid conformance "Class of Product" for WebCGM 2.1, and that all 2.1 
>>interpreters must handle it.
>>
>>2.) say *nothing* in the 2.1 spec about 1.0, 2.0, or other profiles.  (In 
>>other words, use of gzip'd binary CGM in other contexts is by private 
>>agreement about archival and transport, and there will be no suggestion, 
>>MUST, SHOULD, or whatever -- neither implied nor explicit -- in the 2.1 
>>spec about it.)
>>
>>This seemed agreeable to everyone this morning, and seems to resolve 
>>concerns about creating retroactive, even implied, requirements about 
>>already deployed systems for 1.0, 2.0, and other profiles.
>>
>>Are there any objections to this resolution?
>>
>>Other comments?
>>
>>Regards,
>>-Lofton.
>>
>>
>>
>>At 03:30 AM 11/12/2008 -0500, Weidenbrueck, Dieter wrote:
>>>Dave,
>>>
>>>this is pretty much how I feel about this as well.
>>>
>>>The challenge is, if we do #1 inside the WebCGM 2.1 profile, then
>>>
>>>- an unzipped PIP or GREXCHANGE 2.6 file is compliant to the respective 
>>>profile
>>>- a zipped PIP or GREXCHANGE 2.6 file is compliant to ...what??
>>>
>>>If a compliant interpreter can read a GREX 2.6 file in zipped form, is 
>>>this a compliant behavior? If it can't, is the interpreter not compliant 
>>>any more?
>>>
>>>if we set up a rule within a specific profile, it will be valid only for 
>>>that profile. In fact, there is an open question that I can't answer 
>>>here on the road, which is:
>>>Every CGM file compliant to a profile must be a legal ISO8632 CGM. Is a 
>>>zipped CGM a legal ISO8632 CGM? If you read it following the ISO 
>>>standard, you will have to reject the file as non-CGM after the first 
>>>bytes. Or, in other words, is it legal to define zip compression inside 
>>>a profile, or does it have to be a separate encoding?
>>>
>>>Dieter
>>>
>>>----------
>>>From: 
>>><mailto:public-webcgm-wg-request@w3.org>public-webcgm-wg-request@w3.org 
>>>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of David Cruikshank
>>>Sent: Dienstag, 11. November 2008 18:31
>>>To: Lofton Henderson
>>>Cc: WebCGM WG
>>>Subject: Re: CGZ files
>>>
>>> >From a user standpoint, I would lean towards option 1.  That is not 
>>> requiring that cgz only be used with 2.1, but using informative 
>>> language to indicate that cgz files might contain cgm files from 
>>> previous profiles.  My reasoning is based on a question I get all the 
>>> time from people in the industry.  "Do I have to open up every CGM file 
>>> and change the ProfileEd every time the industry profile 
>>> rolls."  Creating a zip content for a CGM file can be done without ever 
>>> touching the file with a CGM tool and I can see where an application 
>>> might take advantage of the cgz file just by converting it's whole database.
>>>
>>>A second question....Does anyone really thing a viewing application is 
>>>going to access a cgz file, unzip it, and the if the ProfileEd is not 
>>>2.1, reject the fiile and not display it?
>>>
>>>thx...Dave
>>>
>>>On Mon, Nov 10, 2008 at 12:34 PM, Lofton Henderson 
>>><<mailto:lofton@rockynet.com>lofton@rockynet.com> wrote:
>>>Hi All,
>>>
>>>As I'm working on the summary of LC comments, I realize that we haven't 
>>>completely put the CGZ question to rest yet -- there are loose 
>>>ends.  (See my summary below attached.)  Benoit mentioned this also at 
>>>the end of the WG telecon.
>>>
>>>About 2.1:  I think we agree that it is a valid content type for 2.1, 
>>>right?  I.e., gzip-compressed binary CGM content is a conforming Class 
>>>of Product for 2.1.  And 2.1 interpreters must handle it.  So we can 
>>>clarify the wording about 2.1 in the 2.1 spec if anyone thinks it is unclear.
>>>
>>>About 1.0 & 2.0:  I sense that people want to be able to exchange 
>>>gzip-compressed 1.0 and 2.0 as well.  Correct?
>>>
>>>So what are the options:
>>>
>>>1.) We could put a non-normative note in 2.1, acknowledging that 
>>>gzip-compressed binary is not conforming 1.0/2.0 content strictly 
>>>speaking, but that it is a useful and used technique, and recommending 
>>>that interpreters should be prepared to handle it.  (And they might 
>>>encounter it in the context of *any* profile of CGM.)
>>>
>>>2.) We could process errata for 1.0 & 2.0, making it a formal 
>>>requirement.  (This would be a *substantive* errata.)
>>>
>>>3.) Other.  E.g. something along the lines of the "storage/transport 
>>>variant outside of CGM".  My question about this option would be:  how 
>>>exactly would such a perspective be reflected in the 2.1 text?  (Is this 
>>>option essentially the same as #1?)
>>>
>>>Regards,
>>>-Lofton.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>At 08:59 AM 10/21/2008 -0600, Lofton Henderson wrote:
>>>
>>>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: 
>>><mailto:public-webcgm-wg-request@w3.org>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>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.
>>>
>>>
>>>
>>>
>>>