RE: Re: Chris -- Please Bless This

["Cruikshank, David W" <David.Cruikshank@PSS.Boeing.com>]

Lofton,

I'll update the editing directives and keep trucking on doing the editing.

thx...Dave

> ----------
> From: 	Lofton Henderson[SMTP:lofton@rockynet.com]
> Sent: 	Wednesday, January 31, 2001 1:36 PM
> To: 	cgmopen-members@lists.oasis-open.org
> Subject: 	Fwd: Re: Chris -- Please Bless This
> 
> All --
> 
> If you are interested in the character repertoire question for Second 
> Release of WebCGM 1.0, read on.  It is interesting to follow Martin's link 
> to Xlink, and to look also at IETF RFC 2396.  RFC 2396 "updates 1738 and 
> 1808" (the URL and fragment specs of W3C).  I have only glanced briefly at 
> 2396, and am going to assume that it is backward compatible to the others 
> (talk about a legacy nightmare, if it wasn't!).
> 
> I'm not sure about his comment on SPACE and other problem characters.  My 
> reading of 1738 (where it belongs to the class "unsafe") and 2396 (where it 
> is classified as "excluded") is that it is URL-escaped:  %20.  He must have 
> some context in mind that is not relevant to our scenario.
> 
> Dave --
> 
> Should we add to the editing directives:
> 
> 1.8.1, update
> Add "RFC-2396, Uniform Resource Identifiers (URI): Generic Syntax, URL: 
> http://www.ietf.org/rfc/rfc2396.txt"
> 
> -Lofton.
> 
> >X-Sender: duerst@sh.w3.mag.keio.ac.jp
> >Reply-To: duerst@w3.org
> >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J
> >Date: Wed, 31 Jan 2001 14:13:50 +0900
> >To: Chris Lilley <chris@w3.org>, Lofton Henderson <lofton@rockynet.com>
> >From: Martin Duerst <duerst@w3.org>
> >Subject: Re: Chris -- Please Bless This
> >X-RCPT-TO: <lofton@rockynet.com>
> >
> >My comments below:
> >
> >At 04:28 01/01/29 +0100, Chris Lilley wrote:
> >
> >
> >>Lofton Henderson wrote:
> >> >
> >> > Chris --
> >> >
> >> > This needs your blessing.
> >> >
> >> > Attached are the changes that we will apply to WebCGM 1.0 (First Release)
> >> > to get WebCGM 1.0 Second Release.  Dave is actually applying these
> >> > now.  (Note that we can't say "Second Edition" like XML does -- WebCGM
> >> > section 1.6 loads the word "Edition" with quite different, and substative,
> >> > meaning.)
> >>
> >>Yes, I followed that discussion and I understand.
> >>
> >> > Half of this stuff is 1-1/2 years old, and the rest is the implementation
> >> > of what we discussed all together in Washington.  I would appreciate it if
> >> > you would take a quick look at the new stuff, and make sure that we 
> >> haven't
> >> > misinterpreted anything.
> >>
> >>I notice
> >>
> >>2.35.1  Correction, 4.3, T.14.5
> >>Change $BE*(BSO Latin 1, LHS$BG(Bto $BE*(BSO Latin 1 (LHS & RHS) and 
> >>Symbol$BG(B  (Not an
> >>XML-alignment issue, just a mistake).
> >>
> >>Agree about RHS;
> >>
> >>'Symbol' is not a charset and should not be added. It was not omitted by
> >>mistake. Unicode covers all the 'characters' in the Adobe Symbol font. For
> >>example, the entity set for HTML 4 includes entities (specified by Unicode
> >>number) and this approach should be followed here.
> >>
> >>'Symbol' should not be added as an erratta because its omission was not an
> >>error.
> >
> >I very clearly and strongly agree with Chris.
> >
> >
> >>also,
> >>
> >>2.35.4  Correction, 3.1.1
> >>
> >>A WebCGM processor shall handle a non-ASCII character in a URI by
> >>representing the character in UTF-8 as one or more bytes, and then escaping
> >>these bytes with the URI escaping mechanism (i.e., by converting each byte
> >>to %HH, where HH is the hexadecimal notation of the byte value).
> >>
> >>It should be made clear that the WebCGM processor is the thing which
> >>interprets the WebCGM file, and not a WebCGM generator (both of these are
> >>arguably processors ....) the important thing being that the URIs in the
> >>actual CGM file have the Unicode (IRI) form and not the escaped form; the
> >>escaping only happens when the URI is about to be sent over the network and
> >>is done by the WebCGM interpreter.> 
> >
> >Yes, this is important. One easy way to clarify it might be to change
> >"A WebCGM processor shall handle a non-ASCII character" to
> >"A WebCGM processor shall interpret a non-ASCII character".
> >But maybe this is not clear enough.
> >
> >An alternative is to use text from the XLink PR:
> >http://www.w3.org/TR/xlink/#link-locators
> >
> > >>>>
> >The value of the href attribute must be a URI reference as defined
> >in [IETF RFC 2396], or must result in a URI reference after the
> >escaping procedure described below is applied. The procedure is
> >applied when passing the URI reference to a URI resolver.
> > >>>>
> >
> >
> >There is also the issue of what to do with ASCII characters that are
> >not legal in URIs, in particular spaces. There is currently still
> >some disagreement on how exactly to deal (or not to deal) with
> >such cases.
> >
> >
> >
> >Regards,   Martin.
> >
> 
> 
> *******************
> Lofton Henderson
> 1919 Fourteenth St., #604
> Boulder, CO   80302
> 
> Phone:  303-449-8728
> Email:  lofton@rockynet.com
> *******************
>