Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hello, I'm a newbie, but I have another view on the DTD issue -- I keep my work journal (the thing I fill out my daily and monthly reports from) with a text editor. I have been using some XML marking in obvious spots, as a kind of thought exercise. This sort of thing obviously isn't ready for a DTD, as it isn't really even well-formed yet. When I take this to the next step (My boss says I must, but he isn't allocating me time yet.), I will use a RAD tool (Delphi, probably) to set up a quick form that wraps the fields I know I'll need with XML tags and appends it to a text file that will be well-formed when it is generated. At this point, I don't really need a DTD, but I probably want to start thinking about it, making scratch notes in the comments in the program code. Until I build the first prototype, I won't know, but I think I eventually want the ability to insert arbitrary tags in several of the fields, particularly the notes field. (Yes, probably mixed content! Do these arbitrary tags have anything to do with the concepts of the Semantic Web?) If I've already built a DTD by this time, I may find that the DTD didn't allow my arbitrary tags. But that would be no big deal, unless I've published the DTD to the whole company, in which case changing it to allow the arbitrary tags might cost the company money. So I probably want to experiment with DTDs after the first prototype, but I don't want to jump the gun and publish any corporate standards just yet. Why do I want to build a DTD at this point? Mostly to help me understand the document class that I am implicitly designing. Now, some time down the road, I have an application that can print my daily and monthly reports for me, straight out of my work journal. If it works well, the boss will want me to make it available to the whole company. At this point, I want a DTD. The reason I want a DTD is that it allows the journal app to publish its interface to other applications (payroll, for instance) to directly extract data from the journal. Just as important, it also provides a reference for other programmers, who will want to to extend the journal application. With the DTD reference, we can extend the journal application in an orderly manner, and the DTD can warn us if anybody's version has become incompatible. Mostly, it helps us keep the extensions from raising incompatibilities. In the case of incompatibilities, it provides the programmer a target when writing the (XSLT? DOM? SAX?) filters to transform the old documents to the new format(s). Likewise, an employee who has his own journal keeping program can use the DTD as a target for the program that transforms his journal into the public form. Summarizing the above, I think you should not use a DTD for any class of documents whose use has not yet stabilized. Once the general use of a document has stabilized enough to make an application for it, a DTD comes in very handy for the programmers. I think there are large classes of documents which simply will not be expected to stabilize into a form that can benefit from a DTD, even though they would benefit from XML. Corporate policies may be one of these classes. (If there is anything certain about rules and regulations, it's exceptions. True?) Having a DTD may help, but any DTD for such applications must be subject to version control. Version control technology is not quite ready for your average secretary to operate. If that's not bad enough, maintaining the DTD current with the present form of the document may incur significant cost to smaller companies. So some companies might well prefer not bother with DTDs for unstable classes of documents. There is information lost if they so choose, and the value of the information lost needs to be considered. If the documents become inaccessible without the DTD, then it is probably best to have the DTD. If they are readable without the DTD, it may well be not worth having the DTD. An aside -- Japanese documents have a problem not so familiar to most American programmers. No whitespace. It's sometimes impossible even for humans to parse word boundaries. This makes normal search functions (the kind of stuff you do with Perl and regular expressions) less effective for Japanese documents. In English, we can easily search for any word that starts with "fidu". With Japanese, it is not easy at all to search for any word that starts with a character containing "kane" as a radical part. But if we preprocess a document and tag the interesting parts, we might be able to get around this problem. (I have an idea for another way to get around the problem, but it would require inventing a completely new encoding method for the Han characters. Definitely not going to be implemented this year.) Okay, bringing Japanese up was just a ruse to motivate the use of XML for otherwise free-form documents. Free-form documents are like the post-cards you send while you're traveling. These are not, in my opinion, amenable to DTDs. Part of the meaning of the document simply can't be encoded, at least not in UNICODE. But one might still want to bury XML tags in a post-card style e-mail message. (Japanese brings this sort of document more into focus for me.) Any comments on this point of view? ----- Original Message ----- From: "Sandra Carney" <scarney@e...> To: "XML Development" <xml-dev@l...> Sent: Friday, May 18, 2001 1:42 AM Subject: DTD's > Hi, > We have a question about the necessity of DTD. There are folks > among our developers who postulate that so long as the document > is well-formed, we don't need DTD's. So far, so true. However, > might this pose a quality problem later on especially if you want > to limit what are considered legitimate tags in the document? > Regards, > Sandra Carney > > ------------------------------------------------------------------ > The xml-dev list is sponsored by XML.org, an initiative of OASIS > <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: xml-dev-request@l... >
|
