[
Lists Home |
Date Index |
Thread Index
]
- From: Rick JELLIFFE <ricko@geotempo.com>
- Date: Sun, 18 Jun 2000 21:15:17 +0800
> At 02:46 PM 6/17/00 -0700, Tim Bray wrote:
> >I'm not sure we'd do it the same way if we were doing it again. I don't
> >see that they do any real harm. Clearly, if you're optimizing for a
> >highly interoperable *content* markup language (and XML is) it's legitimate
> >to be suspicious of things like vertical-tab and backspace and so on...
> >but then how can it be consistent to leave in \n and DEL and so on?
Control characters which are used for flow control and transmission, or
for positioning of teletypewriter heads have no place in a markup
language. They either belong to the networking layers underneath XML,
e.g. ^S, ^Q, ^Z, EOF, EOT, in which case they should have been stripped
out previously, or they belong to hard-coded formatting (e.g. TAB) which
are at odds with how a fully-tagged markup language like XML works.
If a control character does not fit into these categories, it may be
legitimate to include them into the character set that XML can
represent. But if you allow them to be directly specified in XML, you
immediately convert XML into a binary format. If you allowed ^Z in an
XML file, you would find PC editors would find it very difficult to
edit. If you allowed ^S, many terminal based editors or telnet-based
editing would hang.
I think the most that could have been done would have been to make a
rule that you can represent control characters using numeric character
references, but that these references are not to be expanded inline
and/or must be converted back to references when data is generated. But
that in effect re-introduces SDATA entities (data which can be
manipulated and transmitted as references and resolved on an as-needs
basis) which was specifically rejected in XML. Furthermore, it would
probably have required a change to the SGML spec.
I think it was not even requested. However, I do not see it as an
oversight at all. It is consistant with the model. If anyone wants to
encode binary data in XML, they really have to go to bin64 or some other
encoding like that: XML represented data as text not binary, and control
codes are not text. It is reasonable that they require special
treatment.
Rick Jelliffe
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|