Hi all, Thanks to everyone for your excellent suggestions for questions. Some of them weren't appropriate due to the nature of the documents (it's Defence data and they already have DTDs), and some are more general SGML/XML just to keep them on their toes. Overall though, I think it will give them a great running start. Thanks very much for your help.
____________________ 1Q. "Can you explain the difference between standard FrameMaker and Structured FrameMaker?" 1A. An experienced user should be able to explain the differences, even though the difference is just a configuration setting in the same application. Standard FrameMaker is a word processor like Microsoft Word, whereas Structured FrameMaker is all that as well as being a platform to author and edit structured SGML and XML documents, requiring components that control what you can and can't do while creating a document. ____________________ 2Q. What are some of the difficulties that you've encountered while creating structured applications? 2A. Things like defining the structural requirements (the DTD), creating the rest of the application, finding a need to change the structure, then having to catch up with the application. Another difficulty would be imposing a standardised structure on authors or contributors working in Word and not understanding why their data gets changed. Also, setting up for things like images, tables, or landscape pages. ____________________ 3Q. Have them explain their experience in learning FrameMaker - did they do a course, learn it themselves, combination of both? Have they used other structured editing applications 3A. If they did a course, ask them what company provided the training - here in Australia, it could only be one of a handful. For other structured editors, they might claim ArborText, Interleaf or XMetal - experience with any of these would stand them in pretty good stead. ____________________ 4Q. Where would they turn if they found themselves with a problem that they couldn't solve themselves with FrameMaker? Do they have a relationship with any companies that might provide them with support or other contacts? Do they read any of the FrameMaker user groups? If so, which ones? 4A. They'd be pretty brave to try to bluff this one. (There are only a handful of companies training and supporting in Australia.) ____________________ 5Q. Are they willing to demonstrate their proficiency on a simple test document during the interview? 5A. Given a simple document, can they: - Add an element in a place not allowed? - Add an element in a legal place? - Change an attribute value? - Enter text - Validate the document? - Fix the error introduced in the first point and revalidate? Ask them to explain as they go, so the non-technical panel has a better idea what they're looking at for the next applicant. ____________________ 6Q. Have you built structured FrameMaker applications in the past, or just authored with them? If you've built them, roughly how many elements did the DTD contain? 6A. If they claim to have built applications but don't know what a DTD is, show them the door. If they don't know what an element is, show them the window. ____________________ 7Q. Can you explain what a book is in FrameMaker, how it differs to a chapter and what general purpose it serves? 7A. A book is a container that manages multiple chapters, allowing numbering of pages, headings, paragraphs, tables, figures and anything else to be managed from a single point. ____________________ 8Q. Can you explain the difference between SGML and XML? 8A. For a non-technical panel? Next to nothing, really. They use the same pointy brackets. If they tell you that XML is a more portable syntax by virtue of the fact that it's more self-contained, kiss them. Then hire them. ____________________ 9Q. What other XML standards/recommendations are you familiar with? 9A. XSLT, XSL-FO, XPath, XSD, Schematron, RelaxNG, XQuery all score points. ____________________ 10Q. Which popular published structures have you worked with in the past? 10A. ATA, Airbus, 5629A, DocBook, DITA, etc. -- Regards, Marcus Carr email: mcarr at allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein