[
Lists Home |
Date Index |
Thread Index
]
clbullar@ingr.com (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
|
