W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > July 2007

RE: call for 1.0 errata

From: Lofton Henderson <lofton@rockynet.com>
Date: Wed, 11 Jul 2007 16:50:34 -0600
Message-Id: <>
To: "Cruikshank, David W" <david.w.cruikshank@boeing.com>, "WebCGM WG" <public-webcgm-wg@w3.org>

Okay, here is my take on the potential 1.0 errata that Dave has dug out...

At 01:53 PM 7/9/2007 -0700, Cruikshank, David W wrote:
>There may be some overlap with what Lofton has already done:
> >From the discussions with CL on WebCGM 2.0:
>======================== CL-c5========================
> Non-ASCII characters in URIs
>I think that is OK
>***Lofton's Preliminary Assessment***
>Great! We got it right. (This should also be the subject of a clarifying
>erratum for 1.0.)
>Proposed Resolution
>Do nothing for WebCGM 2.0. Add to erratum list for WebCGM 1.0.

Done, this is E01.  Needs to be fleshed out, but it is there in placeholder 


>======================== CL-d8========================
>[[[The address of the link (the first parameter of the 'linkuri') is any
>valid URL according to the rules of RFC 3986.]]]
>That seems to be a change from WebCGM 1.0, which allowed a URI or a
>string that could be escaped to form a URI. Although WebCGM 1.0 v2 says
>"The address of the link (the first parameter of the 'linkuri') is any
>valid URL according to the rules of RFC-2396.". hmmm
>***Lofton's Preliminary Assessment***
>This wording should have been changed and was missed. There is a similar
>sentence in which *was* changed, simultaneous with fixing
> (non-ASCII in URIs). Those changed were made together, to remove
>ambiguity that existed in 1.0, and clarify for 2.0. (They are planned to
>be an erratum for 1.0, to validate the two different, correct readings
>of 1.0).
>Proposed Resolution
>Fix it as just described.

Good.  This might be considered part of E01, or might be separate.  But 
I'll edit the placeholder in E01 [1] so that it isn't lost.

>Telecon Minutes - 1/16/2004
>Revision 1 of Dieter's proposal adopts Lofton's comment (See
>200411/doc00000.doc).  What is not specified are defaults.    The
>proposal was approved.  Dieter needs to work into the proposal a way to
>zoom to some larger viewcontext than the extents of the primitives (e.g.
>-navigating to a callout number when it doesn't have a viewcontext).  A
>"zoom margin" was suggested, but it would complicate the fragment
>syntax.  Forrest asked about a DOM call of get APS extents, like SVG get
>bounding box.
>*       Ben will write a proposal for get APS extents (alternative:
>zoom margin).
>*       Based on the inconsistency that was pointed out by Dieter,
>Lofton will add some wording to the errata.
>*       Continue object behavior details via email.

Handled in separate message,

Bottom line:  no 1.0 erratum here (unless someone object to that 

>Telecon Minutes - 5/5/2005 (not erratum??)
>Lofton is still researching the correct sequence tails for UTF-8 and
>UTF-16.  Once this is done, an errata statement will also be made to
>WebCGM 1.0. NOTE FROM 6/29/05 - This will not be an errata item for
>WebCGM 1.0 - It will be documented in 2.0 in "what's new" and
>"deprecated" section.

Right, no 1.0 erratum (because it would invalidate legacy content).

>Telecon Minutes - 7/14/2004
>Draft an errata statement for WebCGM1.0 Release 2 to deal with the
>conflict on whether name is allowed on para/subpara

I think this is a 1.0 erratum.  2.0 allows 'name' on 'para' and 
'subpara'.  2.0 is written much more clearly about the content model and 
there is no ambiguity.

However, in 1.0, normative [2] says that name is allowed on 'para' 
and 'subpara', but normative 3.3 [3] (content model) omits it.  The latter 
should be fixed with an erratum.

[3] http://www.w3.org/TR/2001/REC-WebCGM-20011217/REC-03-CGM-IC.html#webcgm_3_3

I added a placeholder to the errata document.

> >From last Cologne f2f meeting - is there anything we have to do about
>Mitre Limit?  Was this supposed to be a defect report for SC24?

Hmmm... I think so.  Too bad we forgot that one.  But we can point it out 
to WG6 -- it will just take a slower path than the present defect reports.

Note that 2.0, in the PPF, calls out this problem under MITRE LIMIT [4] and 
additional interpreter requirements [5].


Presumably we want a 1.0 erratum, saying approximately the same 
thing.  (However, we should pay some attention to the wording so that the 
wording does not become problematic when an ISO defect correction is finished!)

I will add a placeholder to the errata document.

>That's what I've found...

Thanks for the contribution!


>Technical Fellow - Graphics/Digital Data Interchange
>Boeing Commercial Airplane
>206.544.3560, fax 206.662.3734
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Thursday, July 05, 2007 7:48 AM
>To: WebCGM WG
>Subject: Re: call for 1.0 errata
>Status report and correction...
>So far, I have gotten zero response on this.  Does no one know of any
>1.0 errata?  I.e., you haven't even marked up your paper copy with typo
>corrections, etc?
>Dave, would CGMO TC minutes contain any references to such stuff?  Could
>you either check them, or divide 'em up and delegate to other TC/WG
>A correction to my earlier message is below embedded...
>At 07:31 AM 6/22/2007 -0600, Lofton Henderson wrote:
> >WebCGM WG --
> >
> >I have started the 1.0 errata document:
> >http://www.w3.org/Graphics/WebCGM/WG/2007/errata-10/webcgm10-errata-200
> >70621.html
> >
> >Please send (to me and WG list) any 1.0 errata you are aware of,
> >whether significant or trivial editorial.
> >
> >In skeleton form, I have included the first two definite errata, E01
> >and E02.  They need to be fleshed out considerably, so consider them
> >mostly as placeholders for now.
> >
> >I had a couple other ideas, E03 and E04.  I think E03 probably should
> >be an erratum -- the 1.0 text about searching priorities, etc, should
> >be clarified that it is "for example" , as 2.0 did (as opposed to some
> >wooly sort of normative specification, as it could be read now.)
> >
> >Upon further thought I think E04 -- correction of designation sequence
> >tails for SF -- should *not* be an erratum, and should be dropped.
> >Looking at how we corrected the goof in 2.0 -- grandfathering the 1.0
> >form of the tail while requiring the corrected form for 2.0 -- to go
> >back and correct it unambiguously in 1.0 would invalidate all presently
> >valid 1.0 content.  Bad idea, IMO.
>The designation-sequence-tail glitch was actually about type S
>(graphical text), not type SF.  It was the 1.0 one-byte bug in how the
>d-s-t is specified in the Character Set List element.
Received on Wednesday, 11 July 2007 22:50:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:23:40 UTC