Re: CGZ files

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 <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:* public-webcgm-wg-request@w3.org [
> mailto:public-webcgm-wg-request@w3.org <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 <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: public-webcgm-wg-request@w3.org
> [mailto:public-webcgm-wg-request@w3.org <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 <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.
>
>
>
>
>