Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Common Word Processing Format
 From: Nathan Young -X (natyoung - Artizen at Cisco) [mailto:natyoung@c...] >> On the other hand, there are existence proofs >> for using HTML for high end publishing. >If you use XHTML for publishing a book you may not get a reduction in >complexity. True. What you get is a reduction of surface area: the number of items, terms or parts needed to manage some repeatable process. IOW, if XHTML + CSS + SVG do the job well enough, I don't have to invest in a word processing system for an alternative format. (NOTE: per job. I might have to for other jobs or for jobs other people do.) >Textbooks have enough complexity and structure and are >different enough from web pages that shoehorning them into XHTML has >costs of its own. Yes. It depends on the job, who does the job, how often they do it, etc. In a software subscription model, one wants to keep costs low by not having apps one doesn't use laying about. If one does need them, then immediate learning curve is an issue, so one looks to the repeatability of the task. In publishing, it is possible the author only needs a simple wp system and an editor and layout artist do the other tasks. If I am a technical reviewer, I want the content but don't always need a well-formattted version; in fact, I want the version I can annotate easily. So now, if I use the XHTML version, I need annotation features or I use a pen. >The tighter a document format is focused on a specific use, the simpler >it can be. Part of the reason that word processing formats are so >complex is that word processors are used for all kinds of things that >aren't word processing. Yes, or jobs that have different tool requirements. The question becomes do I want a swiss army knife or a virtual swiss army knife (blades added on request). Is there a cost break for that? If not, then I have to buy the swiss army knife. >> From where I sit, Bray's namespaced thought experiment >> makes sense. Always has. Structural editors make >> sense. Always have (been doing this a long long time). >I agree they make sense but I really don't think we have them yet. No but that is why we have these conversations. Years ago, we needed a means to distribute technical documents. Now we have that. <snip /> >If you support modularity in any kind of extensible way, you quickly >move from having "a document format" to supporting structured content >with arbitrary content models in an extensible way. That was the SGML dream anyway. It has morphed but whereas it used to have fins and gills, now it has legs and lungs. Meanwhile, PDF is turning into a dolphin. People believe everyone believes in standards. In my career, I have often come up against IT shop managers that look back at me and say, "I don't care. We do things here our own way because we have special requirements." One reason I am not in sales or marketing is a lifelong bad habit of pointing out that might not be true if they take the time to look at the requirements and the possible standard solutions. That is why I am locked up and never allowed to talk to customers. I'm crazy. Perhaps I am. I took this job and that says a lot. >To move to this model my assertion is that you have to specify certain >things about the content format in a way that allows the application to >deal with it. You have to specify: > - how it looks on screen > - maybe how it looks in print > - what content model is valid for the format > - maybe how the editing experience looks/functions and as Mike points out, can one embed live data objects in it. len 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
