dita message
[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
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Grosso, Paul" <pgrosso@ptc.com>
- Date: Fri, 5 Jan 2007 21:52:20 -0500
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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Grosso, Paul"
<pgrosso@ptc.com>
01/05/2007 10:42 AM
|
To
| <dita@lists.oasis-open.org>
|
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: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]