Grosso, Paul wrote:
> 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.
Nice to know someone reads the minutes :)
...
>> 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.
From Michael's email to the list, I thought the same as Paul. However,
during the actual meeting, I understood we were discussing removing the
otherprops attribute. It may well be my misunderstanding. Please can
someone clarify so I can correct the minutes if required.
>
>> 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.
I wrote "consensus", not "DECISION".
When there is a vote, I write "DECISION:" followed by a description of
the actual formal decision taken by the TC. The "DECISION" is preceded
by who moved, and whether there were any objections.
OTOH "consensus" is an informal agreement, not a formal TC decision.
If you prefer that I use other terms, please send me the terms you'd
like me to use with a description of when to use each one.
>
>
>> . . .
>>
>> * 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.
I'll fix the minutes with this. Maybe I should have my hearing checked...
>
>> . . .
>>
>> 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.
I used DTDs loosely in the minutes. I'll update them with the detailed
information you've supplied.
>
> paul
>
>
As soon as I get clarification from TC members on the list about the
otherprops issue we discussed, I'll update the minutes and post the
revised version.
While I try my best to record the meetings accurately, I do make
mistakes and appreciate TC members posting corrections to the list.
Gershon.
