RE: CGZ files

Thanks for the feedback Dieter (and Don as well, for earlier reply).  I 
generally agree with your sentiments, but have some questions about 
implementation.

Questions / comments...

At 06:42 AM 11/11/2008 -0500, Weidenbrueck, Dieter wrote:
>[...]
>No matter which way we go, the problem seems to be that we want to
>introduce gzipping for older profiles or CGM in general.
>
>I can't think of a clean solution other than #2 right now, and I am
>pretty sure that I wouldn't want to process errata for all old versions
>of WebCGM (and potentially ATA, S1000D and other profiles).

Are you keeping in mind that the OASIS process forbids substantive 
(software-changing) errata?  (It would be "artful" to categorize such a 
change as editorial.)


>#1 would establish a firm and clean requirement for WebCGM 2.1 at least,
>and phrase out an option for other profiles.
>#3 would establish a generic viewer requirement regardless of the
>profile.
>
>Problem with #1:
>A conforming PIP-interpreter would not know about gzipping and fail,
>unless the vendor has read and implemented this portion of WebCGM.
>
>Problem with #3:
>Same problem, but at least we could divide the world into interpreters
>(and generators) supporting gzipping as a transport mechanism and those
>who don't.
>
>I'd like to hear other opinions about this, slightly leaning towards #3
>now.

I'm a bit puzzled by how #3 would be implemented.  What text would go into 
what specification, and where?  ("Transport mechanism" currently is not a 
concept anywhere in any CGM standard or profile, for example.)

Regards,
-Lofton.


>-----Original Message-----
>From: public-webcgm-wg-request@w3.org
>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>Sent: Montag, 10. November 2008 21:35
>To: WebCGM WG
>Subject: RE: CGZ files
>
>
>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] 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:07:31 UTC