RE: revised CGZ proposal

I agree with this use case.
 
 >  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."

This statement talks about WebCGM 2.1 viewers (it should rather be
interpreters IMO, how else would IsoDraw be able to read cgz files
otherwise?), and even attaches a version number to the viewer itself. So
to clarify: we are defining the profile version WebCGM 2.1. Is a WebCGM
2.1 interpreter one that is can read compliant WebCGM 2.1 files, or is
it an interpreter version 2.1 that can read WebCGM 2.1 files in zipped
and unzipped form?
 
If the latter is the case, then we can say, that we introduced a version
number for interpreters and their capabilities, which means, that
compliant interpreters must be able to read zip compressed CGM files
from the interpreter version 2.1 on. This doesn't say anything about the
profile or the profile version of the CGM that they would be able to
read.
 
Probably this is too subtile a difference, but if we treat interpreters
this way it would work for any kind of CGM file to be compressed.
 
Dieter

________________________________

From: public-webcgm-wg-request@w3.org
[mailto:public-webcgm-wg-request@w3.org] On Behalf Of David Cruikshank
Sent: Donnerstag, 4. Dezember 2008 20:17
To: Lofton Henderson
Cc: WebCGM WG
Subject: Re: revised CGZ proposal


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.
		
		 >
		
		 >