Groups - DITA TC Meeting Minutes 2 December 2014 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        Sending these out early because there are lots of action items to be dealt with...

ActionItem List:
1. By Dec. 16, JohnH will make changes as needed to L & T section of the archSpec. 
2. Kris will email Jean-Jacques Thomasson, (and cc: Robert, Eliot) to suggest we set up another call with a real translator, and contact possible translators. (EricS?. Jean from Ixiasoft? France Baril is in South America, so not available)
3. Kris will set up a meeting to discuss where to go from here wrt dita.xml.org site RFP .
4. Eliot will archive RelacNG tools on github
5. Chris will go thru comments on key scoping and send email on what he thinks.
6. TC members should try to review the new content in above sections as well as possible.
7. BobT to look through old minutes for all mentions of 'strong & weak constraints to see what we've said about this.


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


Regrets:  Stan Doherty, Dick Hamilton 


Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201412/msg00002.html (25 November, Nancy Harrison)   
Proposed by Kris, seconded by Don, approved by TC

Subcommittee Reports
	scheduled: Lightweight DITA SC 
[In Michael's absence, moved to Dec 9]

Announcements
	Don will chair Dec 9 meeting; Kris may not be available.


Business
========
1. Action items
    Action items from 4 November 2014:
        L & T subcommittee: Make changes as needed to the L & T section of the archSpec. Due by end of 2014. 
Kris; this is an ActionItem for JohnH.
JohnH; it's on my to-do list, will have them done within 2 weeks.
ActionItem: By Dec. 16, John will make changes as needed to L & T section of the archSpec. 

2. Report back from meeting with Jean-Jacques Thommason, DITA-to-S1000D bridge, at DITA Europe
[Kris, Robert, and Eliot had a meeting with Jacques Thomasson; language was a bit of a barrier...]
Robert; the general goal from Jean-Jacques was to make DITA and S1000D more compatible and interchangable. He was trying to put liiteral S1000D markup in DITA and wanted our blessing.  But his implementation didn't follow any of the rules of DITA. I tried to suggest specializing the 'foreign' element, and he seemed willing to consider it as a dual approach, but still wanted us - the TC - to 'bless' his work.
Kris; we owe him a email to clarify our response - which was basically that we couldn't bless his work - because he's moving ahead, and he needs to understand that we can't bless it; it's doing things that are just not technically permitted in DITA. 
Robert; he doesn't seem to understand the specialization mechanism, and so is just hacking DITA to do what he wants.
Eliot; we need someone who both speaks French and understands DITA to talk to him. He's trying to do something useful, but he's not doing it in a way that works with the standard.
Robert; I tried to explain that he could do it with 'foreign', but he wasn't really interested.
Kris; I also talked to him a little after Robert and Eliot left the meeting, but still couldn't make him understand.
Don; maybe Eric Siroisis fluent enough to speak with him...
Kris; or France Baril, or someone else from Ixiasoft; I'll follow up on this.
Robert; He also spoke to vendors on the exhibit floor, trying to get support for his work; some vendors seemed interested...
Kris; he talked to Ixiasoft, so they would be good to talk to him.
ActionItem; Kris will email Jean-Jacques, (and cc: Robert, Eliot) suggest we set up another call with a real translator, and contact possible translators. (EricS?. Jean from Ixiasoft? France Baril is in South America, so maybe not available)


3. Update about dita.xml.org site RFP (Eberlein, Priestley)
Kris; in response to our RFP, we've heard from Mekon and Suite Solutions with interest, and from Ixiasoft for a CMS if we're interested in that; also from another vendor offline. 
ActionItem: Kris will set up a meeting to discuss where to go from here.


4. Continued item: Where to Put RELAX NG Code and Generated Artifacts?
    https://lists.oasis-open.org/archives/dita/201411/msg00069.html (Kimber, 25 November 2014)
[At previous discussion on 12 August 2014; the TC's consensus was that the RNG-to-DTD-or-XSD generator was an auxiliary tool and not maintained by the TC or OASIS. ]
Eliot; I'd like to create one place to put all this stuff, containing at least the RelacNG transforms, and perhaps also the source of the spec (as we have it in SVN)? It's always been publically available...
Kris; but the official repository has to be at OASIS, so that people making changes are OASIS members conforming to OASIS IP policies
Eliot; correct, we would never want to do anything with OASIS code on that site, but anyone can see it.
Robert; once the standard's up on the OASIS site, the spec source is available as a zip file at OASIS, so if someone wants to get it, it's available.  Better to have it only one place, and link to it there.
[TC consensus on having the spec source be only on OASIS site]
Kris; But the TC is very happy to have the transform code moved to github, it's more appropriate, since it's not an official TC project. Is there anything else you wanted to touch on? I think there's TC consensus for you to put it in githiub, in a repository connected with dita-communities. without including the spec source. We don't expect it to serve as a mirror of the OASIS SVN repository.
Eliot; will do that
ActionItem: Eliot will archive RelacNG tools on github


5. 2nd spec review progress: 13 October - 1 November 2014
    REVIEW CLOSED 1 November 2014
    https://wiki.oasis-open.org/dita/1.3-spec-review-#preview
    Update from Kris and Robert
        4.75 hours spent in conference call assigning dispositions of comments (Anderson & Eberlein, each)
        22.75 hours spending handling dispositioned comments (Eberlein)
Kris; we've worked through constraints section, and key scope topics.  Chris, can you do a new topic in this area?
Chris; I think the overview topic has a bunch of material from which you could extrapolate an overview topic.
Kris; Robert and I can point you to comments where people said 'there's good solid material, but it's in the non-normative session.'
Chris; I think this is worth having a further discussion on.
Robert; my personal impression; topic on key scope was very big, and mostly devoted to examples.  The examples and what was around them was moved to examples topics, and that may have moved content that is normative to non-normative section.
Eliot; I had a comment on this as well. The normative topic, before any examples, needs to be some set of paragraphs with the rules the later paragraphs are illustrating, rules need to be stated up-front, not in the examples.
Chris; I'm trying to avoid saying something twice, so I don't want to repeat things in two places.
Kris; I'm the one who moved the examples in exampples sections, so maybe we should talk after you've looked at what's there now.
Chris: I'll go thru comments and send email on what I think.
Robert; the comments that need Chris's attention are marked with status 'referred', and it's probably better to read the comments in SVN, since so much has changed.
Kris; especially since Robert and I are still making changes. Chris, if you can do that, that would be great.  Just let me know; I'll wait to hear from you Chris.
ActionItem: Chris will go thru comments on key scoping and send email on what he thinks.
        The following sections of the spec review have not yet been discussed:
            Processing
                Conref
                Conditional processing
                Branch filtering
                Chunking 
            Configuration, specialization, and constraints 
        Need volunteers for:
            Authoring new topic about scope-qualified key names (Chris Nitchie?)
            Reviewing revised content about linking
            Reviewing revised content about "URI-based (direct) addressing" 
Kris; there need to be extensive changes to 'linking' and 'URI-based addressing', so people will be asked to address those.
Robert; it's hard to tell if people actually reviewed the new content in either those topics or in keys.
Kris; only a small number of TC members reviewed the new content.
Robert; I think that in the past, people avoided it because it was not understandable, but we think it's better now.
ActionItem:  TC members should try to review the new content in above sections as well as possible.


6. Trello items: Spec clarification and improvements
    https://wiki.oasis-open.org/dita/1.3-spec-review-#trello-spec-clarifications 
[discussion of current validity of table in linked document]
ActionItem; Kris will remove #4 ('Clarify how @domains can be used to assemble a doctype') from Trello table, and add it to our backlog for the spec.  
Kris; We've discussed wrt #2 ("Distinction between strong and weak constraints"), we need a volunteer to comb through minutes and dig out what we've decided regarding this topic in previous TC discussions.
ActionItem:  BobT to look through minutes for all mentions of 'strong & weak constraints to see what we've said about this.


7. Review #2 comments:
   - Continued item: Links between maps
        https://lists.oasis-open.org/archives/dita201411/msg00036.html (Eberlein, 4 November 2014) 
   - New item: Subject scheme
        https://lists.oasis-open.org/archives/dita/201411/msg00078.html (Eberlein, 28 November 2014) 
   - New item: Processing key references
        https://lists.oasis-open.org/archives/dita/201412/msg00003.html (Eberlein, 2 December 2014) 
   - New item: Keys in peer root maps
        https://lists.oasis-open.org/archives/dita/201412/msg00004.html (Eberlein, 2 December 2014) 
[discussion on subject scheme and its sp ecial considerations wrt key maps]
Robert; imagine simple map, and a separate [subsidiary] map with keys, it's a local map, so there are easy ways to bring it in. Here, 'peer' means that those keys are not added to my current key space, but they're part of a peer document that I might want to reference.
Chris; 'peer' usually doesn't mean external, but for this, it does.
Robert; what makes me nervous is that adding 'peer' doesn't make it accessible.
Chris; peer has always be described as part of the same system but not the same document.
Robert; in 1.2, the spec described 'peer' as 'not available at build time'. 
Eliot; so is that in the 1.3 spec, or 1.2?
Robert; in 1.2; we tried to get rid of that language in 1.3.
Kris; all the current examples in 1.3 maps shows mapref with 'peer' and @processing-role="resource-only"
Eliot; I don't think "resource-only" has a meaning in this case, because you're referencing a map, but maybe it does...
Kris; we need to figure out what this means and how to say it. 
Eliot; "resource-only" just establishes the ability to reference keys in a completely different publication; either you don't specify a processing-role, or it's "resource-only", since you'd never actually bring the content you're referencing this way into this document.
Kris; have we finished working on this spec content?
Robert; I've checked the spec in 1.2 and 1.3; it specifically says that when 'peer' is specified, it means the content isn't available at build time. I think we should change that to 'might or might not be available'.
Eliot; I agree with that.  We don't want a requirement for conformance to the spec to be that something isn't available.
Robert; otoh, we don't want to say it is available, either. Shall we make them a little less explicit?
JimT; so we're saying it can be either, but are there any processing implications?
Eliot; it's up to the processor if it can make that available.
Chris; if targets aren't available, what should the processor do?
Kris; this goes to the 4th bullet item above 'Keys in peer root maps'.
Kris; are we close to resolution on first bullet item (on 'peer')
Eliot; I'll be happy to change language to establish that if it's available, it's processed, otherwise the processing can be later.
[to be continued next week]


closed at 11:58 EDT
        
-- Nancy Harrison

Document Name: DITA TC Meeting Minutes 2 December 2014

---

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: 2014-12-02 16:27:09