Lists Home |
Date Index |
- To: <email@example.com>
- Subject: Re: [xml-dev] human interaction with XML
- From: "Rick Jelliffe" <firstname.lastname@example.org>
- Date: Mon, 2 Jun 2003 15:28:00 +1000
- References: <r01050400-1026-71E6E9E9937311D7B5F00003937A08C2@[192.168.124.11]> <3ED8F6E1.email@example.com>
From: "Tim Bray" <firstname.lastname@example.org>
> For publishing-oriented apps of XML, we're nowhere near being able to do
> away with entities, and the state of the art for handling them is not
> very advanced.
I suspect that all our analyses of entities/inclusions has been insufficient.
Some "new" information that needs to be factored in to considerations for
XML 2 are :--
* Increasingly we may see that the appropriate level of atomicity
for XML is not the string but the rich string (i.e. text including
inline 'markup' for non-semantic information: i18n stuff such as BIDI,
ruby and gaiji, ad hoc emphases, and probably even ins/del). These
tend to be the things that Unicode Consortium makes characters for,
then W3C deprecates in favour of elements for use in markup: this
may not reflect confusion in I18n people's minds as much as it
shows that we may not have the correct mental furniture (information
items, tags and parsing model) for them.
Other evidence: the issue that people have in XSLT of wanting
entity references moved through intact, and the difficulty with i18n
for XML systems based on plain strings being the atom.
(Perhaps what I am suggesting is a standard vocabulary for rich
text, with some new kind of markup that merges standard character
entities and standard range markers: a cross between entities with
no subelements, PIs but standardized, and elements but non-schematic.)
* Validation mechanisms need to be aware of the inclusion semantic
at some level (where "inclusions" mean replacing one element with
another so that the resulting document will be valid). Xsi:nill suggests
this way, but I don't know that it is actually strong or clear enough.
At the moment, a lot of talk for improving XML is based on replacing syntax
or decreasing the number of information items without a very probing look at
whether there are patterns of deeper problems cropping up that might lead us
to a different model of markup. (Now, I except the parallel/concurrent markup
proposals from this, but they seem to address niche issues.)