[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA Technical Committee Meeting Minutes: 29 March 2011
|
DITA Technical Committee Meeting Minutes: 22 March 2011 Chaired by Don Day <donday@learningbywrote.com> and Kristen Eberlein <keberlein@stl.com> Minutes recorded by Don Day <donday@learningbywrote.com> The DITA Technical Committee met on Tuesday, 29 March 2011 at 08:00am PT for 45 minutes (late start due to phone # confusion). 8:10-8:15 Roll call * Regrets: Eliot Kimber, Stan Doherty, Bruce Nevin * Quorum was established. STANDING BUSINESS: Approve minutes from previous business meeting: * http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00051.html (Bruce Nevin, Tue, 22 Mar 2011 11:28:21 -0500) * Moved by Don, Seconded by Dick Hamilton Subcommittee/liaison reports: Bob Beims for SIDSC: Activity has been low lately; he is working to restart the SC work, which has several new members, had a new kickoff call last week. In a few calls, expects to see getting to new focus. One company wants to contribute their domain to the SC. Next phase is to interoperate data between companies. Kris suggested reordering the agenda; work on #3 first: 3. Extensions to DITA filtering (Jonatan Lundin): Jonatan briefed: Machine industry found not all attrs in DITA are applicable to MI. Subject Scheme came along, looked useful for controlling needed subject values. Could a single filter attr with a generic domain be used in place of domain-specific attributes? Michael: reviewed existing vs potential new input: @props was meant to be semantics-free, can be specialized for backwards compatibility for new domains, as well as binding new subject schemes. Spec is missing a way to bind vaues to a single attribute rather than specializing. Syntax is intended only for generalization. Syntax allows for round-tripping, but is painful for direct authoring. Hence specialization is a better authoring strategy. The proposal for 1.3 is to enable the generalized syntax to be directly authorable and controlled about through subject shceme in the way that specialized attributes are. Jonathan agreed with Michael's review and summary. Pointed out that the DITA values discussion doesn't cover filtering out topicrefs based on subject scheme classification. Michael: Rephrase: given that we have a way to bind subject definitions to filter attribute values, would it make sense to have subject values filtered by property values to have the same treatment as filtered attrs? (noted that IBM is providing a single filtered interface for content coming from many parts of the company) Topicmeta for prolog data is another case needing the common handling. Michael thinks there are other cases (#2) for more complete architecture: * map with topicmeta * map with prolog * attrs in map or topic * subjectref in map only Don: Two issues? documentation on best practices across the board, and specific proposal? Michael: Yes, two technical issues: 1) complex filtering definitions within a single props attr governed by subject schemes, and 2) reconciled metadata schemes for filtering including topicmeta or prolog attributes in subjectref Michael explained current filtering logic based on semantics within the content, noted difficulties with general boolean logic. Issues are: Power to author vs power to reuse. Ways to increase expressability of ditaval file could help increase usability. Jonatan: Worth exploring, needs evaluated carefully. Cascading rules for conditional attributes is another complexity. Michael: More issues for completeness (already noted): 3) Would like to see more flexibility for the cascading (which is currently always additive). Need a way to declare when metadata is a blanket assertion vs a blanket default. Should apply for both processing and scope (branch variation) (this is on the list already) 4) Separating various ditavals with scope (again, already in the list--brought up by Jeremy Griffith) *Actions:* Don, add the two new 1.3 items mentioned by Michael Kris: back to business agenda 1. FAQ item about key resolution: Su-Laine: No new feedback, per Su-Laine. Looking for input on what a processor should display for an element with a keyref, assuming binding has been computed. Concern that what's displayed is undefined. What topicmeta elements should be managed by processor, what is the priority of topicmeta from other content with the keyref on it? Su-Laine is still uncomfortable that the write-up expresses the best interpretations--it might expose problems wiht the stated design. Robert notes the described action is opposite of xref, Su-Laine asserts also not what DITA OT is doing. Kris: what could help us move forward most friutfully? Su-Laine: get Eliot to review more specifically. Kris suggested that Robert and Michael might help. *Action:* Michael and Robert and Eliot to review the key resolution page and most recent email. *Action for all* to do so as well. Plan to discuss next week 2. Conditional processing before/after keyspace construction: No new review comments. Kris urges TC to stay enlightened, needs held for Eliot to be back on the call. 4. DITA complexity: Not enough time to cover today. Back to forefront next week. *Action for all* to look at wiki page and two email messages in the agenda (Stan and Paul)--bottom of the email is germane to this thread. Kris: Any announcements or questions? Doug Morrison noted being at a recent HAT meeting where no one had heard of DITA. Kris asked him to record that observation in the wiki page. Kris asked Thilo to provide survey results for review next week. Next week is DITA NA. Don will chair, Kris will be out. Don noted end of hour; adjourned. ACTIONS: 1. Don, add the two new 1.3 items mentioned by Michael 2. Michael and Robert and Eliot to review the key resolution FAQ page and most recent email. 3. Action for all: review the key resolution FAQ: http://wiki.oasis-open.org/dita/Review-FAQ-#1 . Plan to discuss next week 4. Action for all: review the DITA Complexity wiki page (http://wiki.oasis-open.org/dita/DITA_Perceptions) and two email messages on today's agenda: * http://lists.oasis-open.org/archives/dita/201101/msg00051.html (Stan Doherty, Tue, 18 Jan 2011 11:28:35 -0500 -- recent e-mail on thread) * http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00069.html (Paul Grosso, 22 Feb 2011 13:13:41 -0500 -- scroll down to bottom of e-mail) --
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
|
DITA Technical Committee Meeting Minutes: 22 March 2011
Chaired by Don Day <donday@learningbywrote.com> and Kristen Eberlein <keberlein@stl.com>
Minutes recorded by Don Day <donday@learningbywrote.com>
The DITA Technical Committee met on Tuesday, 29 March 2011 at 08:00am PT for 45 minutes (late start due to phone # confusion).
8:10-8:15 Roll call
* Regrets: Eliot Kimber, Stan Doherty, Bruce Nevin
* Quorum was established.
STANDING BUSINESS:
Approve minutes from previous business meeting:
* http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00051.html (Bruce Nevin, Tue, 22 Mar 2011 11:28:21 -0500)
* Moved by Don, Seconded by Dick Hamilton
Subcommittee/liaison reports:
Bob Beims for SIDSC: Activity has been low lately; he is working to restart the SC work, which has several new members, had a new kickoff call last week. In a few calls, expects to see getting to new focus. One company wants to contribute their domain to the SC. Next phase is to interoperate data between companies.
Kris suggested reordering the agenda; work on #3 first:
3. Extensions to DITA filtering (Jonatan Lundin):
Jonatan briefed: Machine industry found not all attrs in DITA are applicable to MI.
Subject Scheme came along, looked useful for controlling needed subject values.
Could a single filter attr with a generic domain be used in place of domain-specific attributes?
Michael: reviewed existing vs potential new input:
@props was meant to be semantics-free, can be specialized for backwards compatibility for new domains, as well as binding new subject schemes.
Spec is missing a way to bind vaues to a single attribute rather than specializing. Syntax is intended only for generalization. Syntax allows for round-tripping, but is painful for direct authoring. Hence specialization is a better authoring strategy. The proposal for 1.3 is to enable the generalized syntax to be directly authorable and controlled about through subject shceme in the way that specialized attributes are.
Jonathan agreed with Michael's review and summary. Pointed out that the DITA values discussion doesn't cover filtering out topicrefs based on subject scheme classification.
Michael: Rephrase: given that we have a way to bind subject definitions to filter attribute values, would it make sense to have subject values filtered by property values to have the same treatment as filtered attrs?
(noted that IBM is providing a single filtered interface for content coming from many parts of the company)
Topicmeta for prolog data is another case needing the common handling.
Michael thinks there are other cases (#2) for more complete architecture:
* map with topicmeta
* map with prolog
* attrs in map or topic
* subjectref in map only
Don: Two issues? documentation on best practices across the board, and specific proposal?
Michael: Yes, two technical issues:
1) complex filtering definitions within a single props attr governed by subject schemes, and
2) reconciled metadata schemes for filtering including topicmeta or prolog attributes in subjectref
Michael explained current filtering logic based on semantics within the content, noted difficulties with general boolean logic.
Issues are: Power to author vs power to reuse.
Ways to increase expressability of ditaval file could help increase usability.
Jonatan: Worth exploring, needs evaluated carefully. Cascading rules for conditional attributes is another complexity.
Michael: More issues for completeness (already noted):
3) Would like to see more flexibility for the cascading (which is currently always additive). Need a way to declare when metadata is a blanket assertion vs a blanket default. Should apply for both processing and scope (branch variation) (this is on the list already)
4) Separating various ditavals with scope (again, already in the list--brought up by Jeremy Griffith)
*Actions:* Don, add the two new 1.3 items mentioned by Michael
Kris: back to business agenda
1. FAQ item about key resolution:
Su-Laine: No new feedback, per Su-Laine. Looking for input on what a processor should display for an element with a keyref, assuming binding has been computed. Concern that what's displayed is undefined. What topicmeta elements should be managed by processor, what is the priority of topicmeta from other content with the keyref on it? Su-Laine is still uncomfortable that the write-up expresses the best interpretations--it might expose problems wiht the stated design.
Robert notes the described action is opposite of xref, Su-Laine asserts also not what DITA OT is doing.
Kris: what could help us move forward most friutfully?
Su-Laine: get Eliot to review more specifically. Kris suggested that Robert and Michael might help.
*Action:* Michael and Robert and Eliot to review the key resolution page and most recent email.
*Action for all* to do so as well. Plan to discuss next week
2. Conditional processing before/after keyspace construction:
No new review comments. Kris urges TC to stay enlightened, needs held for Eliot to be back on the call.
4. DITA complexity:
Not enough time to cover today. Back to forefront next week.
*Action for all* to look at wiki page and two email messages in the agenda (Stan and Paul)--bottom of the email is germane to this thread.
Kris: Any announcements or questions?
Doug Morrison noted being at a recent HAT meeting where no one had heard of DITA. Kris asked him to record that observation in the wiki page.
Kris asked Thilo to provide survey results for review next week. Next week is DITA NA. Don will chair, Kris will be out.
Don noted end of hour; adjourned.
ACTIONS:
1. Don, add the two new 1.3 items mentioned by Michael
2. Michael and Robert and Eliot to review the key resolution FAQ page and most recent email.
3. Action for all: review the key resolution FAQ: http://wiki.oasis-open.org/dita/Review-FAQ-#1 . Plan to discuss next week
4. Action for all: review the DITA Complexity wiki page (http://wiki.oasis-open.org/dita/DITA_Perceptions) and two email messages on today's agenda:
* http://lists.oasis-open.org/archives/dita/201101/msg00051.html (Stan Doherty, Tue, 18 Jan 2011 11:28:35 -0500 -- recent e-mail on thread)
* http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00069.html (Paul Grosso, 22 Feb 2011 13:13:41 -0500 -- scroll down to bottom of e-mail)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]