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: Groups - DITA TC Meeting Minutes 1 December 2020 uploaded


Submitter's message
ActionItems:
1. Kris will contact Chris wrt the status of his 2 stage 3 proposals, #15 and #16.
2. all TC Charter reviewers - Dawn, Gershon, Nancy - do a review, communicate with each other and Kris wrt comments , bring back to TC by early January.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 1 December 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy


Business
========

1. Roll call
Regrets: Chris Nitchie, Keith Schengili-Roberts


2. Approve minutes from previous business meeting:
17 November 2020
https://lists.oasis-open.org/archives/dita/202011/msg00030.html (Harrison, 17 November 2020)
moved by Kris, 2nd Gershon, approved by TC


3. Announcements
none


4. Action items
[no updates, see agenda for complete list]


5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business discussed]


6. Completing all DITA 2.0 proposals in 2020
https://lists.oasis-open.org/archives/dita/202011/msg00035.html (Eberlein, 15 November 2020)
[no updates]


7. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
[updates only; see above link for complate list]

Stage two
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
01 December: Request for early feedback
[see agenda item 8b for discussion]

(Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
01 December 2020: TC votes
[see agenda item 8a for vote]

Stage Three
***ActionItem: Kris will contact Chris wrt the status of his 2 stage 3 proposals, #15 and #16.


8. DITA 2.0 stage two proposals
a. Vote
#345 "New element for resolving variable text"
https://lists.oasis-open.org/archives/dita/202011/msg00028.html (Eberlein, 10 November 2020)
Kris moved to advance this, Eliot 2nd
Voting results:
yes votes 13 (Robert Anderson, Deb Bissantz, Carsten Brennecke, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Eric Sirois, Dawn Stevens, Frank Wegmann)
no votes 0

- Kris; also, I need reviewers for stage 3, which I've already written.
[reviewers will be Eliot, Deb, Zoe]

b. Early feedback
https://lists.oasis-open.org/archives/dita/202011/msg00045.html (Kimber, 24 November 2020)
[request for feedback]
- Eliot; when I looked at the samples Deb and Scott sent, and reviewed our earlier TC discussion, I realized there's no easy way with current markup. if we want resourceid to be usable the same way copy-to was used. People used copy-to to assign the effective URI for a page, so we need a way to signal that using resourceid so it's distinct from the way people are currently using resourceid. The examples used resourceid to signal a specific processor, so if we add default behavior, that would be wrong. We need a way to say: 'this resourceid is explicitly determining URI for use of topic to which it applies. I can only think of 3 ways (see above email) and the only one that actually makes sense to me is the third one, which is to add a new @ (maybe called @role?) that takes a keyname indicating that it's the effective URI for the topic. That leaves appname unchanged, and processors could use the @role for other things as well. So that's what I'd like to propose.
- Kris; one question. with the suggestion that we add @role, would it be specifying a specific token to be used with that value, but we wouldn't constrain the set of values it oculd be used with?
- Scott; I like that aspect, it doesn't limit what people can do for a custom publishing solution.
- Eliot; I had a question about Stan's example, but it probably doesn't matter in terms of designing this feature. For Scott and Deb, they have completely unqualified resourceids, probably because zoomin just works that way.
- Scott; right.
- Eliot; if it was me, I would have qualified the resourceid's, but it doesn't change the semantics. So if no one objects, I'll update the proposal and get it out by next mtg.
- Robert; I'm wary of an @ named @role, we might want to use 'id-role' so @role could be used elsewhere, which I think it already is. Also, I don't like requiring a name like 'effective-uri' that folks will have to type in, it could definitely be a point of failure.
- Eliot; that's true.
- Kris; it really needs to be usable OOTB.
- Robert; if we gave it enumerated values, without a default, I don't like leaving it unenumeratied, other uses are largely theoretical.
- Gershon; the processor could pick it up
- Kris; I share Robert's concern, I think if we leave it open-ended, how do we cover in the spec what it means?
- Eliot; if the @ is defined as a token list, and we define a token value with a specific value; I don't mind having a set of values be enumerated, we could always undo that in future if it beocomes a problem. We alays have @base which apps can use however they want. I'm not concerned with locking it down.
- Kris; I think we do need a specifically enumerated list, don't want confusion with any other @role we have.
- Jim; in the zoomin example, you could have multiple URIs, so what 'effective-uri' might suggest the only URI, so it might not override the server's URI, 'effective-uri' sugggests it overrides it.
- Eliot; the behavior would just be: 'if this can be made into a URI, this is what that URI should be. It would be 'effective' in the sense that in this context, that's what it is.
- Robert; what about 'delivery-uri'?
- Eliot; that would be good.
- Jim; that sounds better.
- Eliot; I'm just trying to disconnect source uri and delivery uri.
- Kris; this is good, I think we can go from here; we do need reviewers.
[reviewers will be Deb, Nancy, Chris, Robert]


9. DITA 2.0 stage three proposals
[no updates]


10. Changes to OASIS policies
https://lists.oasis-open.org/archives/dita/202011/msg00047.html (30 November 2020)
- Kris; I'd like everyone to look at the changes; does anyone want to be chair or co-chair, or maybe co-secretary? New rules call for re-electing chair every two years. (We used to have 2 secretaries.)
Also, OASIS has gotten rid of excessive drafts, so that's good.


11. Begin discussion about TC charter
Charter: https://www.oasis-open.org/committees/dita/charter.php
- Kris; we need volunteers to look at our current charter, which hasn't been updated in many years. New OASIS rules call for reviewing charter every four years.
- Frank; I can look at it.
- Dawn; what is the timing for review?
- Kris; we're not in a hurry, maybe look at it and susggest changes by early January?
[reviewers will be Dawn, Gershon, Nancy]
***ActionItem: all reviewers - i.e. Dawn, Gershon, Nancy - do a review, communicate with each other and Kris wrt comments , bring back to TC by early January.


Other:
- Zoe; what meetings will be cancelled?
- Kris; either 12/22 or 1/5, I'm open to either or both; if you have preferences, send them to me.



11:47 ET close



-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 1 December 2020

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2020-12-03 22:32:17



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