RE: [dita] DITA Technical Committee Meeting Minutes: 2 January 2007

From
Michael Priestley <>
Date
2007-01-06T02:52:11+00:00
ID
Thread
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