Groups - DITA TC Meeting Minutes 19 July 2016 uploaded

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