- From: David Cruikshank <dvdcruikshank@gmail.com>
- Date: Thu, 4 Dec 2008 11:17:29 -0800
- To: "Lofton Henderson" <lofton@rockynet.com>
- Cc: "WebCGM WG" <public-webcgm-wg@w3.org>
- Message-ID: <8fbe8a40812041117medb649au21d7c827471aef15@mail.gmail.com>
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 UTC