[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    RE: Hopeful suggestion for kword
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-04-27 12:55:41
[Download RAW message or body]

Okay, I have answered to your other mail yesterday, now it is time that I 
answer also this one.

1. XML
Sorry, but it is not XML that is about separating content from markup. 
Putting the formating out of markup has been the task of Cascaded Style 
Sheet, so that a same document (when correctly written) might be displayed 
on a computer screen, displayed on a mobile phone, printed, rendered into 
speech, embossed as braille into paper and so on.

The role of XML was to make a simplier and cheaper to implement version of 
SGML. And SGML (for example DocBook) is about document structure.

2. Searching
Nobody would expect to be able to search directly across words in any SGML 
format (for examples, DocBook, HTML or XML formats like AbiWord's), because 
words can be separated by any inline tag. This has not yet to do anything 
with formatting, formatting just add more of those "breaks".
Please take a look at the example of the chapter 2.2 of the CSS2 
specification http://www.w3.org/TR/REC-CSS2 . This is a XML file and you 
will not be able to search "his flute" !
(And even in Rich Text Format, you cannot search like that!)

2. "Mixing The Two Design"
Sorry, here I cannot follow. What is horrible at, for example ((X)HTML + 
CSS2):

<h1 class="Heading1">This is a title with <span 
style="text-decoration:underline">underlined text</span></h1>

Compare to what would be in a <PARAGRAPH> element in a KWord file to 
describe the same.

3. Structures In KWord
Structures are not a problem. (X)HTML has the <div> tag that can help you 
there.

4. Just Counting Characters
The problem with "just counting characters" is that XML tools cannot do it, 
as this cannot be expressed in any way in a DTD.
When I say XML tools, it also includes other similar tools like Jade.
Additionally you can see in any of KWord's import/export filter how many 
work this character counting does, even in the ASCII export filter!

Have a nice day/evening/night!
-----Original Message-----
From:	Thomas Zander [SMTP:zander@planescape.com]
Sent:	Thursday, April 26, 2001 8:01 PM
To:	koffice@max.tat.physik.uni-tuebingen.de
Subject:	Re: Hopeful suggestion for kword

On Wednesday 25 April 2001 17:30, Nicolas Goutte wrote:
> Yes, but it makes it incompatible with most XML tools, which suppose that
> formating is either automatic ( <?xml-stylesheet ),  in the tags (like 
the
> "id", "class" and "style" attributes of XHTML with CSS)  or inline (like
> for example <b> element in XHTML.)

But that means that the formatting has to be done with extra-tags. Tags 
like
<p> or similar.
That would defeat the whole purpose of using xml.
Again, XML is about seperating content from markup.

Take a page like slashdot (the html), and try to read it.
A xml document like kword is a lot more readable then that because you have 
a
paragraph of text contained in 1 text tag.

If we still want to use XML (and we do) AND do what you suggest, to insert
<p>, <b> etc into the text we would take twice the time for loading since 
we
then mix 2 concepts, the XML concept and the markup-language concept. And
this is very bad design.

To illustrate this in other words;
kword works in structures. We have frames in framesets and paragraphs etc.
This nesting, and structuring is ideally illustrated in an XML document.

Besides the perl script to do what you want to do is very easy to create in 
either case. Its not like its some obscure algorithm hidden in closed 
source
software. Its just counting characters...

And if we would change, in 2 months someone would come along and wants to
search the xml documents, and complains that he can't find "some text" 
since
we have "some <b>text" in the XML...

--
Thomas

[prev in list] [next in list] [prev in thread] [next in thread]