[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SDATA or UNICODE

• From: Arjan Loeffen <Arjan.Loeffen@l...>
• To: Martin Bryan <mtbryan@s...>, Chris Maden <crism@o...>,xml development mailing list xml-dev <xml-dev@i...>
• Date: Wed, 28 Jan 1998 12:54:29 +0100

I'd like to thank the readers for their replies. I'll try to formulate my
thoughts on this issue.

The original EURO/FLORIN question raised an interesting discussion -to me,
anyway- on the status of doing XML 'standardization' work under W3C. In general,
for any new model to be defined, we are forced to build the specs (at least in
part) in a bottom-up fashion. Notably, for XML we must assume there is a solid
way of defining characters, and this must be supported by our software tools.
That way we can focus on information structuring and interchange rather than the
technical issues that *underly* (but are not essential to) any project for
building software. I'd say character specification is an underlying feature. If
we are not certain that we have a *complete* way of defining and referencing
characters (technically, but also socially as is the case for UNICODE assignment
of characters by their external form and use), and if we still want to work on
XML, we must find a 'way out' for those cases where standard character
description fails.

*If* there is no character known as, say, FLORIN, in UNICODE, we must have a way
out and be able to represent (reference) that character. Chris Maden: "There are
a lot of symbols, especially scientific and technical ones, that aren't
represented in Unicode." Martin Bryan's remark: "I agree XML needs to use the
10646 value once it becomes officially approved, but does anyone have the
faintest when that will be?" seems somewhat beside the point; I'd say we can be
sure UNICODE will never be able to represent *all* characters (I may create a new
character every morning at breakfast). When we *know* that there will be
characters such as FLORIN in some knowledge domain/language, and if we assume
there will *always* be such characters that simply have not been recorded before
and/or officially, we must at the very offset of XML standardisation support an
escape route, an alternative. That's SDATA in SGML. If we all agree that we can
never place all distinguishable characters in one world-wide standard (such as
UNICODE), we must introduce the escape route, and not postpone that to a 'future
version' of XML.

So, in my opinion, following the replies to my earlier question, I think XML
should start to support SDATA (as in SGML) and a way of allowing a system to
determine what character the replacement text represents (which is 'covered' by
public character sets in SGML).

PS. Note that SDATA is not a character referencing format: it is a form of
allowing the system to insert *any* data when and where the SDATA entity is
referenced. Notably, this could be a complete character sequence, or even
different data for each reference to the same SDATA entity.

Thanks again for the replies.

Arjan




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: SDATA or UNICODE
    • From: "Martin Bryan" <mtbryan@s...>

• Prev by Date: Re: SDATA or UNICODE
• Next by Date: Re: SDATA or UNICODE
• Previous by thread: Re: SDATA or UNICODE
• Next by thread: Re: SDATA or UNICODE
• Index(es):
  • Date
  • Thread