TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Thanks for the critique. I want to comment on a few points.
-------------------------------
eric dunn wrote:
Designing an XML based language/structure or application from scratch is designing a new XML compliant language. The only way designing a document would create a new language is if you developed your tags ?on-the-go? and aimed simply at a creating well-formed document would be designing a XML compliant language.
regarding (I think):
For example, if you design an XML document for online help, you've just created a new online-help language -- an OHML so to speak.
-------------------------------
Good point. I was attempting to provide an overview without getting into specific details--which by its nature ends up fudging on initial examples to get the point across. It is true that by creating an xml document you are not creating the language. You would need to create a DTD or schema to really say that you've created a language. I had hoped that the phrase "you design a new _kind_ of XML document, you are creating a new language" (my emphasis) made this clear. Apparently, it did not. This issue is clarified in part two when I talk about DTDs and schemas.
-------------------------------
Not true. XML and HTML are NOT ?siblings? of SGML.
said of:
I'll just say that SGML is the parent of XML and HTML. As siblings, both XML and HTML have complimentary roles in data exchange and on the Web.
-------------------------------
Hmmmm. I didn't say XML and HTML are siblings of SGML....
-------------------------------
Format and content are separated only when the designers
strive to implement the separation. The following at least discusses that the design is a state of mind for the designer and not an inherent
requirement of XML. There is no rule in XML to stop you from using an <italic> element.
-------------------------------
True that there is no requirement. But even if you put format information into an XML document, if you don't tell a parser what to do with that information, you're not going to get format. This is different from, say a word processor, where if you mark something as bold you get bold. My intention in including this point was to relate and contrast what a technical writer might typically be used to as far as document production goes and how using XML for document production is different.
I suppose this critique can be examined on several different levels: source, use, output, for example.
If you're looking at just the xml source, then you're right in saying that there is no _rule_ in XML to stop you from using an <italic> element. This does depend on the designer and that point is made.
If you're looking at using XML (including the design of new languages), separation of content and format should drive that use. Doesn't have to, but it should. XML is, after all, a database that stores data. Format information is also data. That data is ignored unless you tell a parser what to do with it. Again, this is different from a word processor where you click bold and you get bold format. Now, I'm talking about what a user sees not what's going on under the hood; most users don't care about what's going on under the hood.
If you're looking at output, without a stylesheet, you ain't gettin squat. :-) Well, you'll get the default "style" as you do when opening an XML document in a browser. You'll get the source if you open it in an editor. But you're not going to get headings at 14 point Tahoma and body text at 12 point shoolbook all arranged neatly in a printable doc. You're not going to get online help with 12 point arial body text and links that highlight green on mouseover. In short, you get content not format.
-------------------------------
The rest seems admirable. Good job Sean.
-------------------------------
Thanks. There's a lot to cover and my hope was to provide enough information to get someone started. The second half has many resources to learn more.
-------------------------------
It's just that without dispelling some of the common myths, and underlining the fact that all the miraculous gains often attributed to
XML are in fact the result of design and implementation effort and not
inherent with the use of XML, I get a little irritated. So don't take the criticism the wrong way.
-------------------------------
Understood. Hey, if I'm wrong about something, I want to know about it.
Good XML design is the key for a successful implementation, because, like the article says, XML doesn't do anything. Hey, since you feel so strongly about it, what do you say we collaborate on an XML design article? <g>
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
