Fwd: Re: Chris -- Please Bless This

[Lofton Henderson <lofton@rockynet.com>]

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
*******************