[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ditaval, metadata, etc
Hello, I recommend you remove any reference to ditaval and "profiling" from the 1.1 definitions. That's implementation stuff, not relevant to a standard definition. I also recommend you strike mention of "conditional processing" from the arch. spec. *All* processing is conditional. A language spec should not be a tutorial on filtering or other processing - you can assume the audience understands that stuff. Labeling one subset of attributes as "conditional" - sounds to me like it reflects the language of the dita-ot implementers; not necessarily wrong or bad, but it shouldn't be in a language definition. In fact I would strike chapter 4 in toto and redistribute its contents elsewhere. A chapter on metadata might be a good replacement; attributes like "platform" and "audience" are just metadata. The spec should not make unenforceable stipulations regarding how dita docs should be used in general nor how such attributes should be processed specifically. In my view the spec should simply state the intended semantics as concisely as possible, no more and no less. By the same token, I don't see any problem with publishing a non-normative Guide that sums up common practices and explains how DITA was designed to suit those practices. But the Standard doc itself should be minimal. As it stands now, the Arch. spec is a mix of user guide, language definition, and tutorial. Don't get me wrong, it's not bad now, but I think it could be better. You could probably fully and precisely define the Arch. in less than ten pages. Not only would that make for a more useful spec. document, I think it would lead to a better "Guide to DITA" document. Sincerely, Gregg Reynolds
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]