dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 17 Februarty 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Tue, 24 Feb 2015 02:20:36 -0800 (PST)
Submitter's message
Action Items:
1. Robert will make the change to 'pgwide='1' statement in table topic in langref.
2. Eliot will move all non-normative content from doctypes and rng directories
3. wrt 'combining metadata from a key reference element and a key-defining element' Robert will talk to Jarno about this, and get him to provide and example
4. Robert will rewrite key definition precedence text (with input from Kris and Chris) and accommodate Eliot's concern
5. Robert will draft a note that basically says, wrt processing key references, 'this is what we think is the right way to do it, but since spec doesn't mandate processing order, might not happen'
=================================================
Minutes of the OASIS DITA TC
Tuesday, 17 February 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: Chris Nitchie
Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201501/msg00130.html (27 January 2015, Nancy Harrison)
Proposed by Kris, seconded by BobT, approved by TC
https://lists.oasis-open.org/archives/dita/201502/msg00015.html (10 February 2015, Dick Hamilton)
Proposed by Kris, seconded by Eliot, approved by TC
Subcommittee Reports
none
Announcements
none
Business
========
1. Action items
- Action items from 2 December 2014:
Eliot: Move RNG-to-DTD-XSD generator code to GitHub (on hold)
- Action items from 13 January 2015
Nancy: Schedule meeting with Jean-Jacques Thomasson
need to re-schedule; nancy & Kris will discuss
- Action items from 27 January 2015
Robert: Remove term from text and examples in "Key processing for text" topic
Robert; may or may not yet be complete; will try to finish this week.
- Action items from 10 February 2015
Robert: Draft new normative languages about keys and subjectScheme
Robert; think I completed, but need to verify
Robert: Remove normative language about comments in XML grammar files
Robert; think I completed that
2. Targeted reviews progress: January - February 2015
[no change]
3. New item: Implication of @pgwide="1" for HTML
https://lists.oasis-open.org/archives/dita/201501/msg00132.html (Kimber, 28 January 2015)
Eliot; current spec says 'pgwide'=1, table is set to pgwide, seems wide impact, either fix that or move it into non normative discussion
Robert; carryover from when processors didn't support other things, but I agree with Eliot
Kris; any objections? hearing none, Robert will make the change to table topic in langref
ActionItem: Robert will make the change to 'pgwide='1' statement in table topic in langref.
4. New item: Which DTDs are "in"?
https://lists.oasis-open.org/archives/dita/201502/msg00001.html (Magliery, 2 February 2015)
https://lists.oasis-open.org/archives/dita/201502/msg00003.html (Kimber, 2 February 2015)
https://lists.oasis-open.org/archives/dita/201502/msg00004.html (Magliery, 2 February 2015)
Tom: there are a couple of directories in the DTD folder in SVN that contain stuff that isn't supposed to be in 1.3, as far as I know; isn't really something that the spec depends on, some items for for Eliot's transform.
Robert; I thought we'd discussed that these were temporary
Tom; that's what I remember too
Eliot; I can move them to be generation code, once I have a place to put it; don't yet have oasis-provided place; agree these aren't part of normative stuff
Kris; Eliot, can you move these from doctypes to someplace else under svn, so someone grabbing thhhis won't get anything extra
Eliot; yeah, I can move that out of the way
Kris; does this apply to more than DTD directories?
Tom; don't know; this is the only one I looked at.
Eliot; I haven't paid attention; I changed some details for metadata tagging
Kris; it looks like those are also in the RNG directory
Tom; yeah
Kris; we'll add an ActionItem for Eliot
Robert; for DTDs under RNG-grammar and vocab-module-desc; all class @s are defined as belonging to class=unknown specialization of shortdesc; I'll send mail as followup; how should we be referencing these things in the spec? I had the impression that they were normative DTDs that are part of the spec.
Eliot; the markup is there because it was needed for DTD generation; so is it normative or just part of this generation tool? I was trying to make that markup a valid DITA specialization, but that may not be possible. The generation stuff is useful, but not part of standard.
Kris; we may have a related 'new item' on next week's agenda
Robert; is there anyone on the TC who has concerns about removing any/all of this kind of stuff? if not, I can just check in with Eliot and report on removals to TC.
Kris; sounds good
[no response from rest of TC]
ActionItem: Eliot will move all non-normative content from doctypes and rng directories
5. New item: Implications, if any, for maprefs in reltable?
https://lists.oasis-open.org/archives/dita/201502/msg00020.html (Kimber, 12 February 2015)
https://lists.oasis-open.org/archives/dita/201502/msg00021.html (Anderson, 12 February 2015)
Eliot; this came up on dita-users group; they were trying to create links from a map (to create a biblio list); it brought up the question of what it means to have a mapref in a reltable. Robert's answer was 'we don't need to do anything, as it's not very useful in a reltable.'
Kris; I have had clients try to do that, vaguely resembling x-deliv linking
Eliot; so we shouldn't say anything else; it's already the case that topicrefs create relationship between the map they're in and whatever we link to.
[no changes required; item is closed]
6. Review #2 comments:
- Continued item: Branch filtering: ditavalref as child of map
https://lists.oasis-open.org/archives/dita/201412/msg00028.html (Anderson, 8 December 2014)
Summary: https://lists.oasis-open.org/archives/dita/201501/msg00067.html (Anderson, 20 January 2015)
Heavy traffic on this item since 20 January; most recent e-mail is below:
https://lists.oasis-open.org/archives/dita/201501/msg00114.html (Anderson, 26 January 2015)
https://lists.oasis-open.org/archives/dita/201501/msg00115.html (Kimber, 26 January 2015)
Kris; we had a discussion on 1/27 which closed this item
[item now closed]
- Continued item: Subject scheme (on hold until after targeted review of subject scheme material)
https://lists.oasis-open.org/archives/dita/201411/msg00078.html (Eberlein, 28 November 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00025.html (Nitchie, 8 December 2014)
LATEST: https://lists.oasis-open.org/archives/dita/201501/msg00069.html (Kimber, 20 January 2015)
[ChrisN is absent; so we'll skip over this?]
Eliot; I thought that Chris and I were in agreement and Robert agreed to craft language
Kris; does this raisea any issues?
[no issues raised]
- New item: Combining metadata from a key reference element and a key-defining element
https://lists.oasis-open.org/archives/dita/201412/msg00018.html (Eberlein, 7 December 2014)
Kris; we have 2 sentences in the spec, and had some discussion between Jarno and Eliot; 'if combining maps and other maps, and maps and some topics conflict, what takes precedence?
Robert; I think he means 'if there is conflict between the rules for combining between 2 maps, and between a map and topic, what takes precedence?
Eliot; it seems the rules are clear, but maybe i'm not seeing where he sees the inconsistency.
Kris; do we need to take this back to Jarno and get an example?
Eliot; yeah, if it's a confuosing use case, we should try to address it if we can
ActionItem; Robert will talk to Jarno about this, and get him to provide and example
- New item: Rules for key definition precedence
https://lists.oasis-open.org/archives/dita/201412/msg00019.html (Eberlein, 7 December 2014)
- New item: Processing key references
https://lists.oasis-open.org/archives/dita/201412/msg00003.html (Eberlein, 2 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00005.html (Kimber, 2 December 2014)
Kris; Eliot says rules for defining effective keys need to clearly state that results will be the same regardless of processing order.
Eliot; my 2nd comment just points out that there was text from 1.2 spec that's not in 1.3; it, or the functional equivalent needs to be copied over.
Kris; I think that text had a term that impedes comprehension, i.e. 'parent scopes key scope'
Eliot; which = key space associated with a parent scope; 1-to-1 between key scope and key space, key scope that's defined by the parent scope
Eliot; but 'key space of a parent key scope' would include the parent
Kris; how about 'key space defined by parent key scope'
Eliot; well, I think that's the 'parent's key space'
Kris; we have to avoid usage that's hard to translate; while the spec isn't translated officially, it's read by many people who translate it 'informally' to understand it better.
Kris; Robert, can you redraft this?
Robert; I'd want to get input from Chris.
ActionItem; Robert will rewrite that text (with input from Kris and Chris) and accommodate Eliot's concern
- New item: Processing key references
https://lists.oasis-open.org/archives/dita/201412/msg00003.html (Eberlein, 2 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00005.html (Kimber, 2 December 2014)
Robert; depending on when you form actual link, you might get different results; I think it's the same as 1.2, but Eliot says this is wrong.
Eliot; as a general rule, processing must be invariant for addressing, so the intent of what was sritten in 1.2, was that 2 processors must produce the same key bindings; they can't get different answers for the same set of filtering conditions; we need to make conditions for key resolutions clearer; for a particular set of key defs and filtering conditions, all processors must get the same set of answers.
Robert; I thought this was recognition that depended on order of processing; some processors do key resolution first, than filtering, others the opposite.
Kris; I think we've discussed this a lot before (in early 2011?); I'll look in the minutes to check.
Kris; we have the question here 'we have particular language from 1.2 that seems to be incorrect' but we can't really turn that language back, ecause too many people depend on it.
Robert; I always feel filtering should come first.
David; we do that filtering first also. we filter while we're building the key space. But you would want it to be the same either way.
Eliot; you can build a key space so it's condition-aware, then filter it. 1.2 language is as Robert asserts, though I think you should never do that. My comment, while true, is not correct
Robert; shall we add a note that says 'this is what we suggest though it may not be done'
Kris; we ready need to mandate processing order in 2.0
ActionItem: Robert will draft a note that basically says, wrt this issue, 'this is what we think is the right way to do it, but since spec doesn't mandate processing order, might not happen'
meeting closed at 11:59
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]