Groups - DITA TC Meeting Minutes 17 Februarty 2015 uploaded

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
        
    

    
        Document Name: DITA TC Meeting Minutes 17 Februarty 2015

        
        No description provided.        

        Download Latest Revision

        Public Download Link
        
        Submitter: Nancy Harrison

                Group: OASIS Darwin Information Typing Architecture (DITA) TC

        Folder: Meeting Notes

        Date submitted: 2015-02-24 02:20:13