Lists Home |
Date Index |
- From: "Neil Bradley" <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 25 Aug 1997 22:51:46 +0000
>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 Bradley - Author of The Concise SGML Companion.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)