re: revised CGZ proposal

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 17:22:17 UTC