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

Re: revised CGZ proposal

From: David Cruikshank <dvdcruikshank@gmail.com>
Date: Thu, 4 Dec 2008 11:17:29 -0800
Message-ID: <8fbe8a40812041117medb649au21d7c827471aef15@mail.gmail.com>
To: "Lofton Henderson" <lofton@rockynet.com>
Cc: "WebCGM WG" <public-webcgm-wg@w3.org>
Good, the classic use case, as I described this morning, is that I've got a
database of thousands of cgm files.  I'm going to implement some WebCGM 2.1
functionality in a few of them and want to take advantage of gzip
compression for all the files in the database.  I do not want to touch each
cgm file to update its ProfileEd to 2.1, just to make us of gzip.

Dave

On Thu, Dec 4, 2008 at 10:56 AM, Lofton Henderson <lofton@rockynet.com>wrote:

>
> Thanks for the comments, Don.
>
> Per today's telecon, Part 1 is closed and agreed.
>
> Part 2, the "lurking question", is what we're seeking comment on.  You
> opined, "...a WebCGM 2.1 viewer should handle legacy WebCGM gziped files".
>  To be precise, the requirement would be phrased for 2.1 viewers that claim
> 1.0 and/or 2.0 backward compatibility.  I.e., if they claim conformant
> handling of 1.0 and/or 2.0 metafiles, then they shall correctly handle
> gzip'd versions of such.
>
> I would imagine this includes all 2.1 viewers in practice, but the wording
> needs to be careful, because a viewer can in theory be 2.1 conformant but
> not 1.0 conformant.
>
> (FWIW, I agree that it is a sensible and practical requirement.)
>
> -Lofton.
>
>
> At 11:21 AM 12/4/2008 -0600, Don wrote:
>
>  Lofton,
>>
>>  >  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?
>>
>> I agree.
>>
>>  >  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?
>>
>> I think that a WebCGM 2.1 viewer should handle legacy WebCGM gziped files.
>> Since the viewer needs to un-gzip to determine the profile anyway, the
>> viewer
>> might as well go ahead and handle the un-gzipped contents.
>>
>> Don.
>>
>>  >  (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 <
>> 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, isit 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] 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 conforming1.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-compressedinstances 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 Thursday, 4 December 2008 19:18:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 December 2008 19:18:06 GMT