[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ditaval should not be normative in 1.1
> -----Original Message----- > From: mpriestl@ca.ibm.com [mailto:mpriestl@ca.ibm.com] > Sent: Tuesday, 2006 November 28 09:53 > To: dita@lists.oasis-open.org > Subject: [dita] Groups - DITA Arch spec 1.1 - work in > progress (ditaspec.pdf) uploaded > > reorganized to make behavior descriptions (eg conref and > profiling) more > prominent - per comments from jeff ogden > added dtd/schema module usage summaries (from robert and eric) > added metadata inheritance/resolution between maps/topics > (from robert) > added conref attribute override behavior > added map inheritance with relationship tables > incorporated second round of jeff ogden comments I also see the following note in this draft (under Conditional processing profiles): jeff ogden: wanted this in a new section of the spec rather than under common attributes. now done. Also, for the record: this is part of the spec. The ditaval format was not normative in 1.0, it is normative in 1.1. There was some old wording from 1.0 earlier that confused the issue, I've removed it. Do we have any record of deciding to make the ditaval stuff normative in 1.1? I don't remember deciding to do so. I've always thought that the ditaval stuff is too implementation specific to be part of the DITA spec--the spec should be documenting the standard, not the Toolkit's implementation--and I certainly think making the ditaval stuff normative in a point release is inappropriate. The consensus at Arbortext is that is isn't a good idea to include ditaval as part of the DITA 1.1 standard. 1) We think the DITA Standard needs to make a clear distinction about what the Standard requires and what is suggested, but not necessarily required, in terms of implementation. We don't think the 1.0 Standard does a good job of making that distinction clear. We think DITA 1.1 will be somewhat better in this regard, but still could be improved further. We think including ditaval as part of the 1.1 Standard adds to this confusion since much or most of the ditaval file seems implementation specific. The Standard talks about "processing" as something that isn't completely standardized. 2) The ditaval file format has evolved rather than being designed. Even if the decision is to include ditaval or something like ditaval as part of the DITA Standard, we don't feel that ditaval as it stands now is ready to be standardized. We think ditaval at this time is mostly what was developed for use with the DITA Open Toolkit and that more work would need to be done to be sure that it is ready to become more widely used by all other DITA-compliant implementations. If ditaval were to become part of the Standard, it would be good if it could become a mechanism that could tie together everything that goes into producing a particular publication. ditaval doesn't do that today. Today we have a map that defines references to other maps and topics. To actually make a publication you need to have the map plus information from something like a ditaval file (Arbortext uses a .pcf configuration file), but you also need information on which stylesheets to use, what directories to use to resolve relative path references, and I'm sure other information that I am forgetting. It would be good to have a way to tie all of this together. Arbortext does not think that ditaval is ready for becoming a normative part of DITA 1.1. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]