Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Are the publishing users happy? Why not?
 clbullar@i... (Bullard, Claude L (Len)) writes: >Should one design the XML (not the editor; >that is a different topic) to enable the author >to edit either the pieces they need to edit at >that time, or all of it at once? Pieces are critical. To use an example I'm working with today, authors and editors at O'Reilly tend to work on chapters of books, not the whole thing. In Word, that's fine - every file is self-contained, and connecting them into a book happens at the very end. In DocBook Lite, there's a book.xml file that contains all the entities used in the chapters, and chapters - being external parsed entities - have no DOCTYPE declarations. I'm packaging up a bunch of the XML tools I use on this stuff so my fellow editors can use them with a minimum of effort, and I'm finding the packaging more difficult than the original construction. Catalogs help a lot, and I'll be integrating my Ents tool at some point, but I'm wasting a lot of time marveling at how much more complicated this is than I expected. >DO namespaces help? Should the editor >be namespace-aware? I'm not aware of too many cases where namespaces matter in the creation of marked-up information. The only case I can think of where they're worth the effort is in mixing various W3C vocabularies for browsers - XHTML, SVG, SMIL, MathML, etc. Even then, a "keep it simple" policy seems crucial. Maybe it makes sense to think of namespaces as the result of a transformation from a human-oriented vocabulary to a computer-oriented vocabulary. >I used to put giant OR groups at the tops of >SGML DTDs to make it clear to the author that they >could choose a part of the document type to >work on. Cheezy, but it did work. Remember, >that this was for a document in which the >types of information are spec'd in advance: >techical manuals, so the author does not have >a much freedom to choose the content types, >the content structures, or the order of entry. Building author/editor freedom into DTDs and schemas seems especially important for these kinds of cases. Schematron's especially interesting in this regard, since it starts from a much more open view of acceptable structure, and seems designed to fit into an authoring/editing cycle. >I agree that thinking of any XML in the same >terms as one builds for a technical manual is >flawed thinking. The doc type can determine aspects >of the task and vice versa. No size fits all. >That aspect made it difficult to build decent >SGML editors, and I suspect, XML editors as >well although XML sanctions well-formedness and >in SGML editors, well, we cheated. ;-) I suspect that cheating will be necessary in XML editors. Well-formedness was a wise concession from authors to developers to jumpstart the process of markup tool creation, but its drawbacks for authors remain. >A point Rick has brought up in the past that >deserves attention: one must be able to turn off >the XML validity checking and edit freely. Definitely. >One of the things XML-Dev has helped with, IMO, >that has been beneficial is Roger Costello's >Best Practices Guide. I review that every time >I have to do a schema. While I assert it is >also important to have this list as a steam valve, >it is at it's best when it is assembling what it >agrees to and making that available in concise >packages. Making xml-dev should spend some time discussing best practices for marking up as well as for constraints? -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com -- http://monasticxml.org 
|
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
|
|||||||||
