dita message

Subject: Groups - DITA TC Meeting Minutes 19 July 2016 uploaded

From: Nancy Harrison<nharrison@infobridge-solutions.com>
To: dita@lists.oasis-open.org
Date: Fri, 22 Jul 2016 23:44:21 -0700 (PDT)

Submitter's message
ActionItems;
1. Kris will update the errata change list to include information about changes to grammar files
2. Keith will discuss google analytics issues with OASIS admin folks, starting with Chet.
3. Kris will open a TC admin ticket for a template for the next committee note (file names and locations)
4. Chris will add issue of schemeref and keys to 2.0 list
5. Kris, Chris, and Tom will discuss restricted values using a subject scheme map further
6. Chris will add his 'include' proposal to 2.0 list
7. Don will write up his transclusion use case

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

Regrets: Robert Anderson, Maria Essi

Standing Business
=================

Approve minutes from previous business meeting:
https://lists.OASIS-open.org/archives/dita/201607/msg00037.html (Tom Magliery, 12 July 2016)
https://lists.OASIS-open.org/archives/dita/201607/msg00047.html (Eberlein, 14 July 2016)
https://lists.OASIS-open.org/archives/dita/201607/msg00066.html (Tom Magliery, 14 July 2016)
Proposed by Kris, seconded by Nancy, approved by TC

Subcommittee Reports
none

Business
========
1. Action items
7 June 2016:
Michael: Post link to slide share of Webinar (COMPLETED)
21 June 2016:
Michael: Provide voting members of TC with link to CIDM Webinar recording (COMPLETED)
Kris, Nancy, Bob: Meet about errata builds
Dick: Review materials about how other TCs use Jira (COMPLETED)
12 July 2016:
Robert; Deb & Maria; Tom: Review revised sections of content model topics (COMPLETED)
Eliot: Make changes to mathmlDomainProxy.rng concerning public ID and refactoring (COMPLETED)
Eliot: Add URI entries to base/catalog.xml for XSDs (COMPLETED)
Eliot: Update the DTD and XSD for learning maps added in 1.3 to match normative RNG (COMPLETED)
Robert: Add item re machineryTaskBody constraint to 1.3 errata list (COMPLETED)
[Kris, Bob, and Nancy will discuss builds after this meeting]

2. Announcements:
- New DITA TC members: None
- XML Mention domain paper has been released by Adoption TC - kudos to Keith

3. Continuing item: DITA 1.3 errata
https://wiki.OASIS-open.org/dita/DITA%201.3%20Errata
DITA-1.3-errata-schedule
Team members:
Editors: Robert Anderson and Kris Eberlein
Style sheets: Bob Thomas
Build: Nancy Harrison
Reviews: Joe Storbeck
SEO and Google analytics: Keith Schengli-Roberts
Work items:
Set up @rev for errata (Completed)
Work errata items related to source (Completed except new example for machineryTask constraint)
Change list (Complete except for listing for grammar files & conditional processing for editions)
Catalog files (Completed)
Correct content model topics (Completed)
Test content model topics (Completed)
Style sheets
Build process
Search engine optimization & Google Analytics
Kris; all content model topics have been reviewed; all work for spec is done except for a new example for machinery task oonstraint.
Kris; Keith, is there anything we need to be aware of in terms of SEO and google analytics? Do we need to have a conversations with OASIS about employing google analytics?
Keith; that would involve talking to whoever actually deploys the docs to make sure that not only OASIS admin, but our chair and sec'ys, can check the standings.
ActionItem; Kris will update the errata change list to include information about changes to grammar files
ActionItem; Keith will discuss google analytics issues with OASIS admin folks, starting with Chet.

4. Continuing item: Work on committee notes
Update to "Why Three Editions"
"Upgrading to a new version of DITA" (was "Upgrading to DITA 1.3")
"DITA the standard versus DITA Open Toolkit"
[no progress]
ActionItem; Kris will open a TC admin ticket for a template for the next committee note (file names and locations)

5. Continued item: OASIS Jira for DITA TC use?
https://lists.OASIS-open.org/archives/dita/201605/msg00038.html (Scott Hudson, 24 May 2016)
Dick Hamilton reviewed materials that Scott Hudson posted to list; discussed at 12 July 2016 meeting
Suggestion for how we use Jira:
https://lists.OASIS-open.org/archives/dita/201607/msg00078.html (Eberlein, 19 July 2016)
Kris; to re-cap mail, I suggested that using Jira required that we have a named DITA TC member volunteer to act as the Jira admin for:
- Opening tickets
- Adding references to TC minutes to tickets, updating tickets as work progresses
- Et cetera
We need to decide, when an action item is opened, whether it needs tracking in Jira.
Kris; right now we don't have enough clarity on 2.0 to decide how we want to use Jira for 2.0; for now, let's use it for 1.3 errata. So do we have a volunteer to do the admin?
Scott; I volunteer for that.
Kris; as we create action items, we should decide if they fit this mold. For example, items that would have fit the mold would have been our changes to grammar files, and content model topics.
Dick; I agree that the main use should be for things that actually have an impact on work items. We should avoid things that are lesser impact.
Kris; I agree. I think if we use if for errata, it will give us a sense for if we want to use it more generally. At the tail end of 1.3, we discussed whether it had been a mistake to have proposals in Kavi rather than in SVN. When we do proposals in 2.0, we should consider where to store them.

6. New item: dita-comment
Gathering restricted values using a subject scheme map
https://lists.OASIS-open.org/archives/dita-comment/201607/msg00000.html (Radu Coravu, 18 July 2016)
https://lists.OASIS-open.org/archives/dita-comment/201607/msg00001.html (Eberlein, 18 July 2016)
https://lists.OASIS-open.org/archives/dita-comment/201607/msg00002.html (Radu Coravu, 19 July 2016)
Kris; wanted to get TC members' feedback on my answer to Radu
Chris; I couldn't find specific info on how should a processor handle multiple xrefs to subjectscheme (SS) maps.
Kris; we have examples in the spec of them being extended down and up. But I think the example Radu gave is a grey area; we never specified a rule for this. In general, the outermost subjectdef value is not available as an attribute value when bound to an attribute.
Bob; so subjectdef has to be a leafnode before it can be included in the list.
Kris; if anyone is particularly interested, we can meet ofline and decide if it needs to be explained in the spec
Chris; it's an edge case because of example; there's a problem with the amount of SS info that's in examples rather than in normative text.
Kris; But do you think the current example in the spec handles this??
Chris; it looks like the same case; one thing needs to be a little different but it seems to be just the same as example in HTML spec section 2.2.3.8.3
Kris; Chris and Tom, can we meet and discuss whether we need to address this specifically
Chris; SS needs more explanation in the spec
Kris; can you add to our 2.0 backlog?
Chris; OK
ActionItem; Chris will add issue of subjectscheme and keys to 2.0 list
ActionItem; Kris, Chris, and Tom will discuss this issue further

7. New item: Interaction between multiple subjectSchemes in a root map
https://lists.OASIS-open.org/archives/dita/201607/msg00017.html (Eberlein, 11 July 2016)
ActionItem; All TC members need to look at this email and think about the questions it raises.
Kris; we need to think about whether we need to clarify what we say in the spec. Please look at normative content AND examples.
Kris; the basic problem is that SS, like constraints, was Erik Hennum's work, but he left the TC before 1.2 was complete.
Eliot; any ref to subjectdef should be just like any other ref; it's only within a SS map that it should have special semantics.
Chris; The problem is that schemeref is NOT available in a domain, just within the structural specialization for subjectScheme.
Eliot; in 1.3, you can use any structural type as if it was a domain, can also create a domain as 'extended-scheme-map.'
Chris; no place in spec where we say how to reference a SS.
Kris; we do say yhat in the 1.3 spec; you can do it either from a map or a parameter passed to the rendering engine.
Eliot; 2.2.3.5 says something else, implies that schemeref is specifically to do that. otherwise, if we ref via a topicref
Kris; spec is really clear with SS ref'd by schemeref, but not how it works if addressed by a simple reference, not by schemeref
Eliot; I haven't read Radu's question, but only a schemeref allows you to treat a SS map as more than simply topicrefs
Kris; let's all think more about it. Chris has a good point that schemeref is only available SS, otherwise what does it mean?
Eliot; since there's no domain for SS, there's no way to have it, if the rule is that only a reference to a SS map via schemeref allows it to be treated, that fails because there's no way to have a SS within a reg map. Usually you reference a SS by using some other map ref; it can't be the case that only a schemeref makes a SS map a subject scheme.
[continued to next week]

8. Continuing item: DITA 2.0 discussion
DITA 2.0: Suggest removing @xtrf, @xtrc
https://lists.OASIS-open.org/archives/dita/201606/msg00013.html (Anderson, 14 June 2016)
https://lists.OASIS-open.org/archives/dita/201606/msg00014.html (Nitchie, 14 June 2014)
https://lists.OASIS-open.org/archives/dita/201606/msg00015.html (Kimber, 14 June 2014)
https://lists.OASIS-open.org/archives/dita/201606/msg00040.html (Tivy, 21 June 2016)
https://lists.OASIS-open.org/archives/dita/201606/msg00042.html (Graat, 22 June 2016)
https://lists.OASIS-open.org/archives/dita/201606/msg00044.html (Eberlein, 22 June 2016)
Eliot; kill them with fire... :-)
Kris; Jang Groot wanted to keep them.
Chris; but anyone can create there own versions.
Kris; they're only there because at DITA's creation, IBM processing required them.
Eliot; once you're in context of any individual processor, you can create your own.
Kris; I'm hearing general consensus to remove these for 2.0.
ActionItem: ?? will add removal of @xtrf, @xtrc to 2.0 list.
[TC accepts this suggestion]
DITA 2.0: Chunking
https://lists.OASIS-open.org/archives/dita/201606/msg00035.html (Anderson, 21 June 2016)
https://lists.OASIS-open.org/archives/dita/201606/msg00043.html (Pairman, 22 June 2016)
https://lists.OASIS-open.org/archives/dita/201606/msg00051.html (Nitchie, 25 June 2016)
https://lists.OASIS-open.org/archives/dita/201607/msg00010.html (Anderson, 5 July 2016)
[continued until Robert is back on call]
DITA 2.0: New include element for base vocabulary
https://lists.OASIS-open.org/archives/dita/201606/msg00052.html (Nitchie, 25 June 2016)
Chris; DITA has a number of transclusion mechanism; coderef, svgref, mathmlref, etc, all are specialized from xref. But xref is a reference, not an inclusion, so the specialization-based fallback behavior for all the transclusion elements are incompatible with the expected processing. So my proposal is to consider adding an 'include', possibly modeled on XInclude, to create elements for doing transclusion
Eliot; agree that we need to have a way to say 'the fundamental working of this link is transclusion', but I think we need to re-architect linking, with basic 'link' divided into navigation (xrefs, links), and transclusion links. This would also provide a base for any other kinds of links if that comes up.
Tom; I'd totally support this; could we redefine all those links to work that way?
Eliot; we could change the hierarchy.
Tom; wouldn't changing the hierarchy be extremely, rather than minimally, backwards-incompataible?
Kris; when it comes to things that are really backwards incompatible, we definitely have to weigh the cost. We have to compare Eliot's proposal with Chris's.
Chris; I'd call Eliot's a modification of mine.
Tom; if we went with Chris's rather than Eliot's, I'd propose to create a bunch of new transclusion elements to replace the current ones that are based on xref.
Chris; to do Eliots's proposal 'would' be fairly disruptive...
Eliot; the other possibility is to introduce a new base of which the topic and map are specialization; could extend specialization system to work better.
Bob; basically, you're talking about introducing a new abstraction layer.
Eliot; I'd like to re-architect the specialization hierarchy.
Kris; from a practical POV, we're still working hard to get the DITA community to think in termns of topic and map as base types, to overhaul that completely would be very disruptive.
Eliot; if we introduced a peer to xref, then in 3.0 we could introduce other things.
Chris; we have a element we could use, and it's called 'data'.
Eliot; data' has processing model of being metadata.
Don; I've run into something that needed a conref semantic; found out that xref seemed to be the closest semantic. I didn't like it, but it worked best. I've used xref in that fashion and found it to be OK, but it 'bruises' the basic xref semantic. We might add an @ to xref the contains app-specific info for data that needs to be passed between apps.
Eliot; we could add info to data as a subelement of xref.
Don; it doesn't really fit the case. I wonder if the 'object' elemetn provides a good spec base for this.
Eliot; the implications of something like coderef; you're creating a relationship between 2 things; you could also render it as 'click here to see the code'.
Don; all of Chris's cases were providing viewports within which to see something.
Eliot; but this is a presentation issue, you could do it differently. One of my concerns with an 'include' element, it should be intended only for references to non-DITA content, not to be used instead of conref. So maybe 'viewport' is better as a element name. Certainly it's a reference to foreign, non-DITA content.
Kris; from POV of mimimizing disruption, that's a lot less disruptive than changing the complete base and class hierarchy for xref and other elements.
Eliot; I'm not sure that I care about changing the class hierarchy - any code that does DITA processing will have to be updated to support 2.0. It would be harder to update not just class hierarchy, but actual business logic. If it's restricted to address resolution, it's not so bad
Chris; There are other ways; there's a lot more code in the world that looks for 'xref' than ones that look for svgref, coderef, etc.
Kris; yes, xref is in all tooling. So, how do we go forward on this?
Chris; it's not urgent, but we should add it to the 2.0 list.
Don; I can write up my use case to add to the background.
Kris; please do, and Eliot, you have a broader view.
Eliot; A meta-question is whether my proposal would be appropriate for 2.0.
Kris; our plan for 2.0 is to be backwards-incompatible, but to minimize disruption.
[continued next week]
ActionItem; Chris will add his 'include' proposal to 2.0 list
ActionItem; Don will write up his transclusion use case

12:00 PM ET Close

-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 19 July 2016

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: 2016-07-22 23:44:02