Lists Home |
Date Index |
- From: Peter@ursus.demon.co.uk (Peter Murray-Rust)
- To: email@example.com
- Date: Tue, 26 Aug 1997 12:39:28 GMT
In message <199708260838.JAA23835@andromeda.ndirect.co.uk> "Neil Bradley" writes:
> 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
Actually I would like to develop CML *without* its own set of rules as far
as possible. OK, Only chemists want to know how to display <ATOMS>, but
there is just as much material of the form:
<P> We took
and we want to know whether there is whitespace round the contained elements.
As I have repeatedly said I would like to borrow a communal solution rather
than invent yet another one.
> 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.
CML is actually aimed very much at the publishing process. I want to be
able to combine text, images, vector graphics, maths, and chemistry and for
a technically oriented published to be able to process it. I accept that
some people think this merging of XML from different sources is
unrealistic, but there are others who share the same vision - we'll find
out soon enough whether it's a disaster! In any case, we can always
mix and match using XML-LINK EMBED.
> 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
Could you expand this? It is intended to produce a single official style
sheet that covers all of this?
> 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 would strongly argue against Unicode characters at this stage. *I* wouldn't
know where to get them from, and typing by hand could be a disaster. It
will take a while before Unicode is natural to HTML authors.
> 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.
Don't despair. There seem to be a group of people on this list who think it's
worth pursuing. Several ideas have been suggested. If nothing else it's
probably worth summarising what they can do and where they fall down
(seriously). If they can be encapsulated in a stylesheet, perhaps so much
The problem is probably knowing where to draw the boundary as to what these
rules will accomplish. Solve part of the problem and see if it appeals to
a sufficient number of people.
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)