OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

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

"Grosso, Paul" <pgrosso@ptc.com>

01/05/2007 10:42 AM

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
>         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.


>         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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]