I think you misunderstood me.
I know we voted "to deprecate the
otherprops grouped value syntax". That was not the issue about which I
said "I don't remember an official
vote/decision on this--did I miss something here?".
I said that about "Consensus that [implementations] do not have to support deprecated
elements."
The minutes show no motion and second for this issue, and I
do not remember voting on it. Do you believe we did?
Furthermore, it makes no sense to vote on such a statement
because there are no implications to the spec unless we decide to put wording
into the spec to this effect, and I certainly don't remember deciding to do
that.
So I still believe we had no vote/decision about "Consensus that [implementations] do not have to
support deprecated elements" and still request that the minutes be
corrected to reflect this (unless I am proven incorrect, in which case the
minutes should be corrected to show the motion and second).
paul
From: Michael Priestley
[mailto:]
Sent: Friday, 2007 January 05
20:52
To: Grosso, Paul
Cc:
Subject: RE: [dita] DITA Technical
Committee Meeting Minutes: 2 January 2007
Re the decision to deprecate the
otherprops grouped value syntax:
>I don't
remember an official vote/decision on this--did I
miss something
here?
It went by quickly :-)
We did have a motion and a second and no objection because it was faster than
deciding whether it was actually necessary to do so.
I believe your other points are all correct.
Michael Priestley
IBM DITA Architect
and Classification Schema PDT
Lead
http://dita.xml.org/blog/25
"Grosso, Paul"
<>
01/05/2007 10:42 AM
To
<>
cc
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:]
> Sent: Friday, 2007
January 05 03:24
> To:
> 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
