faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: newbie see newbie do
by Nick on Friday 15/Mar/2002, @00:25
|
XHTML is a subset of XML. There are strucutures and data that you would want in a document that XHTML cannot represent. However, using a good transform you could automatically turn an XML Kword file into XHTML. That would be a much cleaner way of doing things.
Keeping the conversion apart from the file format gives you good abstraction and it's a lot easier to maintain. If the XHTML specs change you just change the transform and not the Kword XML file format.
The whole point of XML is that you can easily defined rules to convert it. As for the syntax of XML: it's self descriptive. You read the DTD and you can understand exactly what it represents and how to validate an XML file.
XHTML is just XML with a particular DTD. The world wide web consortium has pages decribing this www.w3c.org and there are plenty of good books on the subject.
CSS is a good idea, keep the display details apart from the content. However CSS is *not* defined using XML and it's syntax is horrible. When it gets replaced with a good XML based definition then things will improve. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: newbie see newbie do
by Nicolas Goutte on Friday 15/Mar/2002, @14:41
|
That is not the same!
There is a big difference about a file that you could display in any browser and a file that you *could* transform to HTML.
As for KWord's DTD, it is not as self-descriptive as you are assuming it, for example <FORMAT>.
As you are telling, XHTML is well described! That is the biggest advantage! New developpers will not need to learn KWord's DTD but could have better documentation. They would only need to learn the private extension of KWord, the rest would be XHTML (modular.)
I had tried to tell that back in 2001, but I did not managed to get my position understood.
As for CSS, it will never be defined in XML, as it purpose is exactly to remove such information from XML or (X)HTML.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Carbon on Saturday 16/Mar/2002, @00:46
|
Well, for one thing, when XHTML was designed, much of HTML's features were moved to CSS to help bring HTML back to it's original purpose, as a language to describe content in a way that seperates it from page layout. However, KWord, being a DTP, is more suited towards having these in the same unit, and CSS isn't XML anyways. Also, word processing requires control and expandability of many aspects that no version of HTML/CSS has. Some of these things are:
* Fine-grain image placement : Thats in CSS only as of XHTML 1.0
* Margin and coloration control : Also in CSS
* Typeface and properties control : You guessed it, CSS
* Embedding : KWord has the abilty to embed any properly coded KPart into it's document. XHTML has no such generic insertion mechanism, aiui.
* Frames : KWord's DTP capabilites allows for framing, that is, dividing a collection of paragraphs arbitrarily and automatically into multiple connected areas. This is good for multi-colum pages, etc. XHTML has no such capability, last I checked.
I'm fairly sure that there are other things that should be on this list that I'm forgetting. What all this means is, XHTML is not a suitable general purpose DTP or WP language. Exporting to XHTML/CSS is a good idea for web development (certainly, exporting valid XHTML would be a pleasant change from what Word does) but with a document of any complexity, you're probably going to lose, at the very least, some of your editing capabilities.
Ugh, and using propreitary XHTML extensions is a horrible idea. That would require reimplementing much of what CSS is already designed to do with XHTML, and that would be tantamount to a complete fork of XHTML. At that point, the standardization (which was the point of using XHTML in the first place) goes 'Whoosh!' down the drain.
What would (and IMO should) happen to make something generic and standardized possible is if the various OSS office suite developers were to agree on a generic XML based format. This isn't too likely to happen any time soon, though, as most of the office suites are still working on feature impelementations (Abiword, KOffice) and/or code cleanups (OpenOffice), and changing the core file format would core changes that at this stage in development, would be a complete PITA to implement.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nicolas Goutte on Saturday 16/Mar/2002, @12:09
|
As you are writting, what you cannot do in XHTML, you can do it in CSS.
The enhanced (former "style") mode of KWord's HTML export filter shows the way.
Frames can be done using <DIV> elements and by placing them with CSS. It is the way that I plan to use for KWord's HTML export.
The only thing so far that I have found that do not exist in XHTML are variables. But that would only mean one or two private attributes (which type of variable and which format) in a <SPAN> element.
XHTML modular explicitely allows private definitions and if you do not use them, you have only XHTML. And even if you use them, it does not mean that the result becomes not "displayable" in a browser.
Therefore the problem is not the file format itself.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Navindra Umanee on Tuesday 30/Jul/2002, @12:30
|
Thank you for posting suspicious code here. I will keep my eye on you.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
