A question for you, Geoff... What's your position on the necessity of a technical writer to spell, or to understand grammar? Is that a "nice to have" or a "requirement". Following your argument that a software tool can hide those technical nasties like CSS and HTML markup from the user, surely FrameMaker, with its grammar checker and spell-checker can also hide the technical nasties of spelling and grammar from the user. I would think that without spelling and grammar, you could produce a decent document. Nothing flashy, not particularly good, won't win a Booker prize, but it's only for a dull and dreary policy-and-procedure intranet with no budget! With Dreamweaver skills but no interest in HTML and CSS principles, writers usually produce content that doesn't comply with accessibility requirements. A simple case in point... if you style your CSS using point sizes instead of percentages, the text on your page can't be displayed in a larger or smaller text size by people with poor eyesight. We're meant to be professional communicators, and that means having more than a superficial understanding of the "tools" we use to communicate, including spelling, styling, content structure, authoring tools, writing methodologies and delivery formats. Obviously, I think that knowledge of spelling and grammar is a requirement for a technical writer. I also think that an understanding of those XML principles that apply to technical communication is a requirement for a technical writer wanting to develop a career in the industry. In explaining how little a writer needed to know about XML, you used the terms DTD (EDD), blocks, elements, attributes, and content rules. Those following this thread who don't have any idea about XML will realise that these terms and concepts are critical to understanding what we're on about! (To pre-empt another argument, it's irrelevant whether XML "invented" those concepts. They are still XML concepts.) Cheers Tony >>> "Geoffrey Marnell" <geoffrey@xxxxxxxxxxxxxx> 11/09/2008 10:37 am >>> Thanks Peter, We seem to be in complete agreement. Taking into account all your conditional statements, it seems that we have both answered Nikki's original question the same way: knowing XML is not "becoming part of a REQUIREMENT for a Tech Writer". Further, you write "If you really want to know how to use structured documentation based on XML, it really is very important to know a bit about what's going on under the bonnet". This is not the case at all. There are companies who use structured authoring merely to instil structural discipline on their authors. A DTD (or EDD in FrameMaker-talk) regulates what blocks of text can go where, forcing the authors to follow a predefined set of content rules. Saving the file as XML is another step altogether, and is not necessary. (That is, you can save a structured FrameMaker document as a FrameMaker file. You are still doing structured authoring, and you can do so without knowing a single thing about XML. (Yes, you need to know about elements and attributes; but these are general concepts, not tied to XML. They were part of structured authoring well before XML surfaced.) But even if we go one step further and save our structured documents as XML, how much about XML do we really NEED to know? If I'm just going to open the file again at a later date, I just point FrameMaker at it and it opens. If it is going to be repurposed by some other author, I just check it in to some CMS or other repository: no XML skills needed here. In this scenario, the XML code thus generated, and the deeper XML-based application routines, are of no concern to me. Let me repeat from an earlier message in this thread: knowing what XML is is useful (and knowing what structured authoring is is even more useful, bearing in mind that the two are not inextricably linked). But that doesn't mean that knowing this stuff is a *necessary* requirement for working in technical writing. My concern with Nikki's original post was that a whole lot of young readers relatively new to our profession might get the impression that they will never break into technical writing unless they learn XML. And that's just bollocks. Even if every single documentation project were to be based on structured authoring (which will never be the case) authors would still be able to get by without any detailed knowledge of XML. Structure is structure; what comes out at the other end is something different. If we don't accept that then you'd have to accept that SGML and XML are one and the same.) Let's extend this even further: most non-FrameMaker XML-generating workflows require XSLT or XSL-FO to render the raw tagged text as professionally formatted documents. It's professionally formatted documents that technical writers are expected to deliver. So are we going to say further that knowing XSLT and XSL-FO is also becoming a necessary requirement for a technical writer. Again that's bollocks. Just as we left the pain of learning HTML to the propeller heads who created GUI editors, we (that is, technical writers) will leave the pain of text rendering to the propeller heads (and those dabblers in technical communication who are probably better described as "documentation technicians") to provide the necessary GUI interfaces for applying format to structure. (Already in FrameMaker, by the way.) And I still stand by my statement yesterday that you don't need to know HTML to produce decent websites. Yes of course there are bugs in HTML editors and numerous browser incompatibilities. And I agree that if you want to reproduce the flashy, script-driven, multi-layered design you have in your head then it's likely that you'll only get that with code-kludging, precisely because of those bugs and limitations. But for every flashy, script-driven, multi-layered design there is a thousand simple effective websites generated by the tools I mentioned that do what they were designed to do. Technical writers don't work as graphic artists: they don't approach their tasks with an Australian Design Award in mind. Most of the HTML work we get to do is dull and dreary policy-and-procedure intranets where budgets deny us the pleasures of flashy, script-driven, multi-layered designs. And thus we get by without needing to know HTML. All the design and styling dialogs in, say, Dreamweaver keep us happily away from the tags and tangles below the bonnet. Crikey, next we'll be saying that knowledge of JavaScript is a *necessary" requirement of becoming a technical writer just because sometimes Dreamweaver buggers up JS. Nice to have, perhaps...but surely not a necessity. Again, I swing the conversation back to Nikki's original question: requirement versus nice-to-have. Cheers Geoffrey Marnell Principal Consultant Abelard Consulting Pty Ltd T: (+61 3) 9596 3456 F: (+61 3) 9596 3625 W: http://www.abelard.com.au -----Original Message----- From: austechwriter-bounce@xxxxxxxxxxxxx [mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of peterm_5@xxxxxxxxxxxxxx Sent: Wednesday, 10 September 2008 6:48 PM To: geoffrey@xxxxxxxxxxxxxx; austechwriter@xxxxxxxxxxxxx Subject: atw: Re: XML - a requirement for a TechWriter looking forwork? Geoffrey: Nothing quite like an extended metaphor, but let me put it this way. I don't have to be a qualified mechanic to drive a car, anymore than I have to be a C# programmer to use some accounting software. But if I want to be a competent driver, it helps to know: 1. which bit the engine is under (VW drivers please note) 2. which holes take water and which take petrol 3. to use petrol in the tank instead of kerosene, and which type of petrol 3. what to do about a flat tyre 4. what to do about a flat battery. And a few miscellaneous "specialised" items, even such things as what gear to use going up a hill, and how to handle a rear wheel skid and a front wheel skid are things that are extremely useful (and hard to follow if you don't understand the mechanics of what's going on so you can detect a problem beforehand). Of course you can drive a car without really knowing all of these things. But doing it well does seem to require a few of the above "specialist" items. I can get in and start an engine, get a car into gear, turn a wheel, etc for a while, and that's driving, but it's not effective driving for long if I don't know at least something about the other "stuff". And just as I'm going to look bloody silly trying to pull the load of a B-double with a Toyota Corolla, it's important to know the limits of what can be done and ideally, why those limits apply, so that I don't waste time attempting the impossible. If you really want to know how to use structured documentation based on XML, it really is very important to know a bit about what's going on under the bonnet, unless you don't mind dying wondering... I earlier mentioned that knowing how to fix stuff (which implies knowing how stuff works) is a handy skill to have if you want to work effectively and economically. That's as true with documentation tools as it is with cars. When everything works, it's all rosy in the garden. Don't know about your garden, but we still have aphids, bugs, washaways, soggy bits etc in our garden. And people have been gardening for centuries. Dreamweaver works ? Yes, maybe. It didn't usta write valid HTML, and those of us who used it then were grateful for any insight into how to make its output work properly. It usually meant hacking changes in the raw HTML. You could be a tech writer working with only plain text. Somewhere. Used to happen. Once upon a time. --Peter M ************************************************** To view the austechwriter archives, go to www.freelists.org/archives/austechwriter To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject field (without quotes). To manage your subscription (e.g., set and unset DIGEST and VACATION modes) go to www.freelists.org/list/austechwriter To contact the list administrator, send a message to austechwriter-admins@xxxxxxxxxxxxx ************************************************** ----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. ************************************************** To view the austechwriter archives, go to www.freelists.org/archives/austechwriter To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject field (without quotes). To manage your subscription (e.g., set and unset DIGEST and VACATION modes) go to www.freelists.org/list/austechwriter To contact the list administrator, send a message to austechwriter-admins@xxxxxxxxxxxxx **************************************************