RE: CGZ files

 Lofton,

Please see inline.

Regards,
Dieter

-----Original Message-----
From: public-webcgm-wg-request@w3.org
[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
Sent: Dienstag, 11. November 2008 16:07
To: Weidenbrueck, Dieter; WebCGM WG
Subject: 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.)
DW: This comes on top of my concern above. So to be clear: I do not want
to do #2, because it would mean substantial hazzle with a _lot_ of
profiles IMO.

>#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.)
DW: I am uncertain about this as well. We have choices:

- declare it to be an additional encoding 
->would then basically require a change to all profiles current and past
to allow for this encoding. 
->identical to #2, which I don't want to do

- declare it to be a viewer feature
->this seems to be the way to go. We also expect a viewer to support
http, ftp, file, and other transport schemes without explicitely naming
or explaining them. If we find the right wording it might work, but it
might have to sit outside of the WebCGM profile then, perhaps in a
separate document?

Regards,
Dieter


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 16:24:16 UTC