[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA Technical Committee Meeting Minutes: 2 January 2007
With due respect to (and appreciation for) Gershon's minute taking, there are several points that I believe may need correcting in last meeting's minutes. > -----Original Message----- > From: Gershon L Joseph [mailto:gershon@tech-tav.com] > Sent: Friday, 2007 January 05 03:24 > To: dita@lists.oasis-open.org > Subject: [dita] DITA TC Meeting Minutes: 2 January 2007 > 2. ITEM: Ongoing review of 1.1 drafts > > * Architectural Spec: > http://lists.oasis-open.org/archives/dita/200612/msg00033.html > > Don: Some list feedback on Michael's questions. > > Michael: Should we deprecate the grouped value > syntax for conditional property values in otherprops? > List discussion was in favor of deprecating. > > Paul clarifies that this means we'll pull the > element out in 2.0, not 1.x. Actually, we're talking about deprecating just one form of the value of the otherprops attribute, not an element. > > Michael moves to deprecate otherprops in favor > of adding new attributes. That was not my understanding. I understood that we were just deprecating the grouped value syntax in otherprops. I did not understand us to be deprecating the otherprops attribute completely. I request that we clarify this decision and correct the minutes as appropriate. > JoAnn seconds. No objections. > > DECISION: Deprecate otherprops with documentation > to recommend adding attributes. > > Discussion on whether implementations must support > deprecated elements. Consensus that they do not > have to support deprecated elements. I don't remember an official vote/decision on this--did I miss something here? I thought we just had a non-normative discussion about what implementations--in particular, the toolkit--should do about the deprecated grouped value syntax for otherprops. Besides, it makes no sense to have any actual vote/decision on this unless we plan to put something normative into the spec about support for deprecated things, and I don't remember seeing any suggested wording for such. Assuming my memory of the status of this discussion is correct, I request that the minutes be corrected to reflect this. > > . . . > > * Remaining questions: > http://lists.oasis-open.org/archives/dita/200612/msg00034.html > > Michael proposes to remove the following sentence: > "The rule may be relaxed in future versions of DITA > if a mechanism is added for tracking dependencies > between structural and domain specializations > in use by a document type." > DECISION: To be removed. No objections. > > Michael proposes to remove the reference to architectural > forms from the class attribute discussion. > Some TC members pointed out the comparison may not be > useful as an explanation of the class attribute. Proposal > to rewrite to stand on its own to describe the class attribute. > Michael: This is only a wording change. If no objections, > I'll make the change. > Paul: Why not just remove the sentence making the comparison > and leave the rest? Actually, that's not what I said, and... > Michael: yes, that works. ...no, that doesn't work (and Michael didn't say that works). What I said is that it doesn't just work to remove that sentence since the following sentence which starts: Also, DITA scopes values by module type (for example topic type, domain type, or map type) instead of document type... which will no longer make sense when we remove the previous sentence. That is what I pointed out, and Michael agreed. So... > DECISION: Remove the following text: > "It's something like an architectural forms attribute, > except that it contains multiple mappings in a single > attribute, instead of one mapping per attribute." ...in fact, what we decided was that Michael would remove that sentence and then we directed the editor (Michael) to wordsmith the following sentence appropriately. > > . . . > > Don: Has anyone used the 1.1 DTDs yet? > Gershon: we are integrating DITA 1.1 DTDs into a > CMS at this time, and expect to have a fully working > product implementation in about 2 weeks. > Paul: We have included the 1.1 DTDs in the Arbortext > Editor that was released recently. In fact, we are using/redistributing both the latest DITA 1.1 DTDs and XSDs in Arbortext 5.3 which we just released 2006 Dec 29. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]