Whitespace

[Neil Bradley]

>Sean Mc Grath
> >On Mon, 25 Aug 1997, Sean Mc Grath wrote:
> >> User A : "What file format is that?"
> >> User B : "It's MicroScape XML."
> >> User A : "I better buy a copy of MicroScape so - otherwise the white space
> >> will get busted again".
> 
> [Liam Quin]
> >If this happens, it wlil be time to standardise whitespace handling at the
> >applicaton level, perhaps.  Right now, I fnd this argument totally bogus.
> 
> What are you saying? Lets wait and see if the horse bolts - if he
> does we will lock the barn door?
> 
> Sean Mc Grath
 
I agree with you totally. The horse will bolt, for certain. I want to 
be able to use XML editor A, and allow people to view the 
output on browser B and C, publish it on DTP system D,
send the data to someone else using editor E,
and let people search for pseude-elements using extended pointers
in products E and F, and all without extra spaces appearing or
vital spaces disappearing at any point.

I cannot understand why some people think this will not be problem. 
We are getting extreme views here, from let the XML processor handle 
it, to let every application do its own thing. Neither position is acceptable. 
OK, lets rule out special cases. I can accept that CML and CDF etc 
will have their own strict rules, perhaps, but I am far more 
concerned with general document editing and publishing (the sort of 
things HTML and SGML have been primarily used for).

Personally, I am happy to say this issue is beyond the XML processor, 
and should be handled by the application. Fine. But let all 
PUBLISHING RELATED applications adopt the same guidelines. Too many 
developers are going to miss problems which we could help avoid if we 
could arrive at even a partial setof guidelines. Personally, I think 
we can achieve more than this.

Do we want XML to gain a reputation as an unreliable 
data exchange and publishing format?

We should not have to burden document authors with processing codes, 
etc. People want the ease of use of HTML (and, dare I say it, SGML 
too, in this respect at least). I still think this is unnecessary. 

Others have recently proposed the style sheet as the answer, and I 
agree. My original proposal to base some of the rules on in-line/block definitions 
assumed this approach. It is more reliable than 
element content versus mixed content. I do not, however, think we 
need to go as far as waiting for the official DSSSL based style sheet 
to be completed. I for one do not believe all XML-aware applicaitons 
will use it, and certainly not in the short term. Any config file or 
style sheet will suffice.

People are also proposing all kind of Unicode special characters to 
perform vital tasks. Let's remember here that few people even have 
the specification, let alone use this set extensively. I am sure its 
time will come, but let us be realistic. XML is going to be in 
widespread use first, and needs to be workable with 7-bit ASCII, if 
possible, and ISO 8859 if not.

I did not expect the rules I (nervously and tentatively) proposed to be acceptable. 
But I did hope they could form the basis of detail discussion, from 
which a better set of rules would emerge. Unfortunately, we seem to 
be getting nowhere. I am trying not to depair. But it's hard.

Neil.

-----------------------------------------------
Neil Bradley - Author of The Concise SGML Companion.
neil at bradley.co.uk
www.bradley.co.uk

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)