RE: CGZ files

Lofton,

Good reply. Just to clarify:

>So in short, I'm not inclined to reopen the requirement issue for 2.1.
I don't want that either.

>That said, there is a valid question what people want to do about 1.0
and 2.0, where it would be just as useful, but where it was not proposed
in time to be part of those base specifications. 

That's all that I am asking for, and it may be out of scope for this
discussion around WebCGM 2.1.

Regarding your interop comments:
I basically agree, although we have that situation now. Not every
interpreter is a viewer, so not every application that is able to read a
WebCGM is able to execute embedded links etc. This doesn't look like a
problem to me.
With regard to the zip compression, we should leave it as is for 2.1,
but then probably have a more generic discussion about this for WebCGM
and CGM in general.

Regards,
Dieter

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Dienstag, 21. Oktober 2008 20:17
To: Weidenbrueck, Dieter; WebCGM WG
Subject: RE: CGZ files

Good questions, Dieter.  I have some opinions (surprise!)...

At 05:39 PM 10/21/2008 -0400, Weidenbrueck, Dieter wrote:
>[...]Following your conclusions:
>
> >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?
>
>So that raises a question for me:
>If we agree that zip compression is more like a "transport feature"
>(like ftp compression btw), and if we agree that it is legal to zip a 
>1.0 file and decompress it before a v1.0 viewer can read it, then Why 
>do we add zip compression to WebCGM at all?

I think the idea was to ensure that a 2.1 generator could safely gzip a
2.1 metafile, and be assured that all conforming 2.1 viewers would
handle it.

It was patterned after how SVG did it.

>Why don't we define a
>pure viewer feature like many others to handle zip compression?

I'm not sure I understand this point.  For 2.1, I though we did
essentially place a conformance requirements on viewers, that they must
be able to handle gzip-compressed binary-encoded WebCGM instances.  What
am I missing here?


>For example, we expect a viewer to download files from a server using 
>the usual protocols, however, that protocol (e.g. http) is not part of 
>WebCGM itself.

Indeed.  And there are many other ways that the metafile can arrive at
the viewer.  (DVD, flash memory, etc.)

>Could we possibly simply distinguish between viewers that support 
>zipped CGMs, no matter which version and profile, and viewers that
don't?

If I understand correctly ... this does not seem to be a good route to
widespread interoperability -- dividing the world into viewers "that
can" 
and viewers "that can't", on something we have already endorsed (for
2.1) as useful.

I.e., vendors A & B generate gzip regularly, and interpret it.  Vendor C
has a viewer that regularly receives .cgz from A & B.  But vendor D
never receives A & B metafiles, and so doesn't bother to implement .cgz.
Until that day when ...etc...etc...

I think that scenario potentially gives CGM a black eye -- "doesn't
work."


>Supporting the OBJECT tag of HTML is not a part of WebCGM at all, still

>the viewer needs to support it.
>
>I guess I am not sure where to put this, perhaps somebody has a good 
>idea.

We enumerated and endorsed the requirement some time ago (August 2007).
I see it as useful, as do some others.  I'm satisfied to go forward with
it in 2.1, as a normative requirement in 2.1 on viewers.  It might not
be architecturally pure, and there are consistency questions like you
raised about OBJECT and HTTP.  (Although I personally consider them to
be one step further removed from encoded metafile content.)

Plus ... we know that it will pass muster in W3C, since it is exactly
what SVG does about compression.

So in short, I'm not inclined to reopen the requirement issue for 2.1.

That said, there is a valid question what people want to do about 1.0
and 2.0, where it would be just as useful, but where it was not proposed
in time to be part of those base specifications.

Regards,
-Lofton.

>-----Original Message-----
>From: public-webcgm-wg-request@w3.org
>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>Sent: Dienstag, 21. Oktober 2008 11:00
>To: WebCGM WG
>Subject: RE: CGZ files
>
>
>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 Wednesday, 22 October 2008 01:46:46 UTC