Re: [xml-dev] human interaction with XML

["Rick Jelliffe" <ricko@allette.com.au>]

From: "Tim Bray" <tbray@textuality.com>

> 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.) 

Cheers
Rick Jelliffe