Groups - DITA TC Meeting Minutes 19 May 2015 uploaded

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

        Submitter's message
        Action Items:
1. EricS will create an intermediate XSD Schema to update infotypes for troubleshooting doc shell to allow task rather than troubelshooting as a nested element.
2. Kris will work with Bob and Robert to help set up clean publication of a working draft using OASIS transforms to get the right footers. zipfiles, etc.
3. Nancy will set up call with Kris and Tom re: planning package structure and getting OASIS buy-in on that structure.
4. TC, in particular ChrisN, Eliot, Robert, and Kris, will correspond to come up with correct wording for the agreement reached during the TC call wrt key scopes within subjectscheme.

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


Regrets:      Stan Doherty 


Standing Business
=================
Approve minutes from previous business meetings:
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201505/msg00068.html  (5 May 2015, Dick Hamilton)
Proposed by Kris, seconded by Nancy, approved by TC
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201505/msg00118.html (12 May 2015, Nancy Harrison), 
May 12th minutes just posted today, will vote on them next week

Subcommittee Reports
	[Help SC was scheduled today, but Stan sent regrets; will hopefully get his report next week.

Announcements
    Meeting to select vendor for dita.xml.org at 1 PM ET today; contact Kris Eberlein if you want to attend. 


Business
========
1. Action items
   - Action items from 14 April 2015
        Kris: Talk to Mark Myers about peer maps and new learning maps
        Chris: Topic about linking and @format and @scope 
Chris; done, submitted for comments
   - Action items from 28 April 2015
     Robert: Clarify with OASIS what needs to be in the comments for XML grammar files 
Robert; making progress on this; need to follow fup with Chet Ensign to make sure we understand all requirements.
   - Action items from 5 May 2015
     Robert: Revise draft spec to show that source and othermeta do not cascade
     Kris: Soften wording in spec about subjectScheme and ontology management
     Kris: Contact Suite Solutions and Nokia/Microsoft about whether they are using extension feature of subjectScheme
     Kris: Review 1.2 spec to ensure that normative content does not mention extension feature 
   - Action items from 12 May 2015
     Eliot: Update grammar files to include sections for domain and structural constraints4. 
---------- long discussion --------------
        Eliot: Update troubleshooting shell to allow nested task
Eliot; worked on this; posted message on XSDs; will be complete as soon as changes are committed.
- Kris; do we need any discussion of this?
- Eliot; yes, a bit.
- Robert; let's have that now.
- Eliot; basic problem is that we need to change the info-types definition in troubleshooting shell to allow only task; for DTD and RNG shells, that can be done in one step, but for XSD, it can't. For XSD, in one change, we can update it to allow task, but not disallow troubleshooting; as I see it, we have 3 options:
1. let the XSD version be different, in allowing both task and troubleshooting as nested topics. 
2. change troubleshooting infotype tI to 'no-topic-nesting'.
3. allow for an intermediate group file, so that we can disallow all topic nesting, and then add task in the intermediate file.
- [Robert; I'd ignore XSDs since I'm not an XSD user.]
- EricS; are the XSDs available anywhere?
- Eliot, yes, but not with these changes.
- EricS; infotypes are usually defined in the schema, not in the mod file.
- Eliot; the issue is that, using 'redefine', you can allow things, but not disallow things; would need to add an intermediate step.
- EricS; I believe that in 1.2 the group was added, but it was blank, because you can't define infotype in the actual .mod file
- Eliot; in task.mod for 1.2, the task infotype is defined as allowing task or infotypes.
- Joann; the reason we put 'task' structure in troubleshooting topics was that user studies said they needed it.
- Robert; and we added content to the spec to fix problems with the test; previous version was 'broken' and we fixed that; what we're doing now is defined not as breakage, but the way it works.
- Kris; we've now defined in the spec the ability to reuse structure, and we have markup to let that happen.
- Bob; this isn't a problem with reuse, it was caused by allowing task to be nested in troubleshooting.
- EricS; my vote would be to make the intermediate step; take out troubleshooting, then add task.  It's not the 'best' solution, but it makes things uniform among schema types, s- o we should do it.
- Eliot; that seems correct; it would also be useful to have an example of that, in case someone wants to do something like it in other places. Eric, can you do that for us?
- Eric; I can do it; do you want to generate it, or should I just or just stuff it into what's there?
- Eliot; at this point, XSDs are not re-generateable.
**ActionItem: EricS will create an intermediate XSD Schema to update infotypes for troubleshooting doc shell to allow task rather than troubelshooting as a nested element.
----------  end of long discussion ------------------
     Robert: Update "Using keys to address DITA elements" to remove text per minutes from 12 May 2015
- Robert; done
     Robert: Update "Processing key references to generate text or link text"
- Robert; done
     Kris: Add item to DITA 2.0 list about combining and cascading metadata 


2. Report on status of working draft
   - Style sheets (Thomas)
   - Transformations (Thomas)
Bob; I need to have a chat with you, Kris, on this; need help with 2.0 transform.
Kris; we can't spend any time on trying to make the 2.0 transform work for 1.3 OT; we'll make it work with 1.8.5 and publish it that way.
Robert; sounds good; would like to get 2.0 working over the summer
Kris; I agree; we need to just get it out and work with 1.8.5, and commit to using only 1.2 grammar plus xmlmention domain to publish. Robert; I don't know what further OASIS reqs we need to work on for 1.8.5 OT
Robert; justification; we are coming down to the wire about getting this out; no time left to try to get it to work with latest OT.
Bob; I'll try to finish up items working with 1.8.5 toolkit
Kris; Bob, do you need a meeting with anyone else?  We just need to get basic transform stuff working.
** ActionItem: Kris will work with Bob and Robert to get things working for OASIS transforms footers. zipfiles, etc.
   - Content (Anderson and Eberlein)
   - XML grammars (Kimber)
   - Related e-mails:
     Build results uploaded
          https://lists.oasis-open.org/archives/dita/201504/msg00180.html (Eberlein, 28 April 2015) 
     Need feedback about file names and footer info for CHM and HTML versions of the DITA spec
          https://lists.oasis-open.org/archives/dita/201504/msg00173.html (Eberlein, 28 April 2015)
          https://lists.oasis-open.org/archives/dita/201505/msg00030.html (Ensign, forwarded by Eberlein, 5 May 2015) 
     Work required to get a working draft of the spec out
          https://lists.oasis-open.org/archives/dita/201504/msg00088.html (Eberlein, 14 April 2015) 
** ActionItem; Nancy will set up call with Kris and Tom re: planning package structure and getting OASIS buy-in on that structure.


3. Targeted reviews progress: January - May 2015
   - Schedule for targeted reviews:
        Progress on branch filtering: Comments assigned dispositions; editing in progress
        April 28-May 5: Keys (25 pages, including 15 pages of examples) -- CLOSED; editorial work completed; review and comments archived
            TBD: Direct addressing  
        Configuration, specialization, and constraints: Volunteers requested
            TBD: Configuration and specialization 

Kris; we're done with keys; I've uploaded a copy with change markup; Robert and I are trying to get spec ready to have the next review done in the next two weeks; including direct addressing (easy) and more difficult content about configuration and specialization.
Robert; We spent most of last week working on config. and specialiation; this is an area of the spec that grew thru 'disorganization'; there's been no work on  organizing it since 1.0, some glaring holes; e.g. specialization and processing. also config and coding practices, will be fun (!) for everyone to go thru, and we'll rely on Eliot a lot. since he wrote a lot of it originally.  We need to get all sections done in next 1 1/2 weeks so we can review them all?
Kris; there's lots of work coming up; but this is the only way to get 1.3 out in 2015. comments?
Tom; silence is agreement
Don, Nancy, Bob agree.
Kris; appreciate it. any other technically minded people who might have time, we will tap you.
Eliot; I'll help, but I'm already booked.
Chris; ditto


4. Report about dita.xml.org:
    Meeting today 5/19 at 1 PM ET to select vendor 
don; having meeting today; have enough info to make decision; for everyone attending, you need to have looked at the 2 1-hour videos; please be ready with your eval thoughts.


5. Continuing item: Use case for key scopes within subjectScheme
    https://lists.oasis-open.org/archives/dita/201504/msg00170.html (Eberlein, 27 April 2015)
    https://lists.oasis-open.org/archives/dita/201504/msg00176.html (Nitchie, 28 April 2015) a 
Kris; I saw use case for key scopes; I ran into a conflict where I tried to use "example" as a value for both @outputclass and @otherprops, and thought key scopes might let me do this; after bringing up case to the TC on email, I got response from Chris saying it was an 'edge case?'
Chris; having never implemented subjectscheme myself, I wasn't sure about it; I don't know what the right answer is; to me it seems that subjectscheme whould not have its own keys processing.  I'm finding that OT and Oxygen have leaned more on keyspace rules as it relates to taxonomy; I'm still trying to find the right answer, i.e., whether key scopes in this case would be workable.
Kris; I brought this up because as an info architect, one primary way I've used keys has been with clients with controlled values in a subjectscheme. so that's where I see a place where the 2 features intersect.
Eliot; so you have 2 subjectdefs...
Kris; if you want to use the value "example" for the value of both @otherprops and @outputclass, how can you do that without key scopes? (see the example from the email above)
Eliot; I would say this is a misuse of keys, but I can see that key scopes address that problem, so I support the following usage; keyscopes within subjectscheme, are ignored for processing in the general map processing, but used within subjectscheme processing. 
Kris; you lost me
Eliot; ss a mechanism, keys as defined in 1.2 never talks about including subjectscheme in a map, only as a separate parameter.
Robert; that's not written in 1.2, but it's been considered an omission.
Kris; and we specifically fixed that omission in 1.3
Eliot; but a subjectscheme can still be given as a separate parameter to a map
Robert; that's not clear in 1.3, it's there, but not stressed; the implication is that you refer to a subjectscheme from a map. That was the mindset during 1.3 development; there's a lot of language that implies you call it from a map; it's not the default understanding of content.
Eliot; I think you ignore key scopes defined outside the subjectscheme, but use scopes defined within the subjectscheme. otherwise, it would be impossible to apply.
Kris; I think as a TC, we've never really thought about the intersection of keys and key scopes wrt subjectschemes.
Robert; that's true, so i don't know how to come to a resolution on this issue.
Chris; if the current language means that this behavior falls out of it, thats fine; we can just document it.  But I don't know who could authoritavily review such content. maybe Eliot? Kris? Robert?
Kris; subjectscheme is something I like, so I'll really think about it. I don't want to draw a ilne in the sand on this, but I'm bringing it up because we need to think about it; we really overloaded keys in 1.2, so let's be careful.  If i were not in TC, I would 100% expect this to work.
Eliot; in your example, thers a difference between what you want and what I said; what you want is correct.  We need to say: the rule is that, for the purpose of validating values in attributes, the groups subjectdefs that contain groups of values are scope-qualified, but subjectdefs as defined within groups are not scope-qualified.
** ActionItem; TC, in particular ChrisN, Eliot, Robert, and Kris, will correspond to come up with correct wording for the agreement reached during the TC call wrt key scopes within subjectscheme.


12 noon ET Close 
        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 19 May 2015

---

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: 2015-05-22 20:52:56