[JDEV] Writings from the Journal of TCharron

[Scott Robinson]

Interleaved response.

Scott.

* arh14 at cornell.edu translated into ASCII [Wed, Aug 04, 1999 at 01:23:24PM -0400][<Pine.SOL.3.91.990804131428.3558D-100000 at travelers.mail.cornell.edu>]
> 
> On Wed, 4 Aug 1999, Scott Robinson wrote:
> 
> > What you said is along the lines in my head. I'll spew my thoughts some
> > more, since they have been a bit more refined.
> > 
> > First off, since we love being able to debug manually with telnet, the C/S
> > MUST support ASCII. Moreover, since UTF-8 has ASCII and it is the XML
> > standard, therefore the C/S should support UTF-8. There is really nothing
> > suprising here, but I'll just put that down.
> > 
> > Second, I was waiting for the proper time to discuss UNICODE... which was to
> > be my suggestion. Personally, and I'll admit I have not yet screwed around
> > with expat, although I've received the vibes it is quite difficult to change
> > charsets in mid-stream, I believe that since the XML standard allows for a
> 
> Sorry if I'm thick, but what would be the reason for switching 
> charsets in mid-stream of document parsing?  Wouldn't the entire XML doc be 
> normalized to one standard, and, given a message encoding parameter, the 
> client would decide what it wants to do with the normalized characters?  My 
> understanding is that the XML markup itself should never deviate from a 
> pre-stated charset, but the CDATA might (which, really, the parser doesn't 
> care about, right?).  If a standard is set, it will ultimately be the 
> client's responsibility to make sure all outgoing messages are 
> normalized, and all incoming messages are reconstituted in their favorite 
> Star Trek dialect.
> 

Hmm. Let me think a sec.

Ok, I'm about to make an idioitic comment, but it's only because I'm the
kinda guy that thinks this way. I see no reason not to allow for alternate
characters in XML. I'll allow the point that it would only cause confusion
later on and gives no functionality; however, in some future bizarre
universe everyone _could_ be sending data across whatever we use instead of
sockets in some strange charset. I would build in the functionality for the
_XML_ (not CDATA) being in alternate charsets.

Moving to the current CDATA topic... I believe many messages ago the
suggestion for adding a package for specifying what charset the CDATA is in
was made. There were arguments again, but they were
anti-internationalization ones. The only alternative given was a tag. A
<message charset="charset/unicode>...</message> solution is the nicest one
in my mind.

> > charset different from UTF-8, that the C/S should be able to use that
> > particular feature. I would note, that if the C/S cannot understand UNICODE
> > (just an example) there should be a way of saying it. ala HTTP's "Accept:
> > charset/ascii, charset/utf-8" and "Deny: charset/unicode".
> 
> Should you really rely on the facility of XML to use different charsets?  
> Really the only thing that needs to change charsets is the CDATA of 
> users' messages.  The markup itself never needs to deviate from a set 
> standard encoding.  This standard encoding should be broad enough to be 
> able to store every other encoding clients might want to use.  You don't 
> want to change the nature of the messenger based on the characteristics 
> of the message (if that makes any sense).
> 

I believe my drivel was becoming overlapping. Let me seperate. The
"messenger" should be able to support different charsets and the "message"
inside should be able to be completely different.

> > 
> > Standardizing on UNICODE, though, might be a way to go. I'm not sure, but if
> > the C/S plain receives/sends ASCII, it could just convert inside and
> > everyone could be happy.
> > 
> > The following comments are certified werid.
> > 
> > Scott.
> 
> an interloper,
> Aaron
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/19990804/61aeda1c/attachment-0002.pgp>