Groups - DITA TC Meeting Minutes 31 January 2017 uploaded

[Tom Magliery<tom.magliery@justsystems.com>]

        Submitter's message
        Minutes of the OASIS DITA TC
Tuesday, 31 January 2017
Recorded by Tom Magliery
link to agenda for this meeting:	
https://wiki.oasis-open.org/dita/Agenda-31-January-2017

Meeting opened at 8am Pacific time

1. Roll call
Regrets: Carsten Brennecke, Eliot Kimber, Dawn Stevens

2. Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201701/msg00097.html (Nancy Harrison, 24 January 2017)
Motion to approve by Kris
Second by Bob

3. Announcements:
Michael Priestley will join us at 11:30 AM ET, and we will start on discussion about Lightweight DITA and template-based specialization at that time.

4. Action items
20 December 2017
Keith: Investigate whether Canadian companies can get R & D tax credit for working on standards
- Keith checked with his company (IXIASOFT)'s CEO who confirmed none of this is eligible for the tax credit, matching what Stan said before about US policy.

No updates on other action items.

5. Continuing item: Formal work on DITA 2.0
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2

Items for discussion:

Add a new vocabulary element for inclusion of external XML and text markup #8 (Chris Nitchie)
https://github.com/oasis-tcs/dita/issues/8
This came out of our implementing coderef, svgref and mathmlref.
These elements are derived from xref.
Usually we think of xref as being a method for referring to another item, not for transcluding, so this is a fundamentally changing in processor implementation as compared with the base type.
Default processor generalization would "fail".
So we need a new base element with an expected processing default of transclusion.
Scott: with this proposal if someone included something that did not validate against the DTD, how do we handle that?
Chris: at that point you have a broken document, there's nothing on the DITA side we can do about it
In the case of parsed XML currently our two examples (math, SVG) pull in content in a namespace, whereas DITA never is in a namespace
We could put language in the spec that says we strongly suggest markup be not in a DITA namespace
Don: The mechanism is most similar to data notations in SGML; the only thing missing is the type attribute, then a processing tool would specifically retrieve the object and wrap pre tags around it
Kris: I would warn against that, @type is overloaded and is already inconsistent throughout DITA
Don: This was just a suggestion because we do not have any other attribute that conveys the essence of another object. We might need another attribute added to this proposal. Perhaps "@parse".
Bob: Perhaps something like mime-type or content-type would make sense
Don: That's fine. It would require us to use the formal names
Robert: I'm not sure we need to settle on an attribute name in this meeting
Don: I have no qualms with using xref as the basis for the proposal
Bob: I thought that this would be in lieu of xref, and would be a new basetype
Chris: That was the proposal and would that be my preference
Kris: Would we change the specialization hierarchy so the other elements (coderef etc) would be based on the new base element?
Chris: Yes, indeed it has to be a new base element because it has a new attribute (@parse)
Robert: I think it would be better as a new base element, because of the new/different semantics
Bob: Yes, we overloaded xref when we added it
Don: I have a use case question, often I transform DITA docs into forms so they can be used to create new content by filling in the xref, but at the same time the info is not in a database and the next time I open that document it needs to retrieve that content from the element's source. Would this new element serve as a query element?
Chris: Now we're talking about using DITA as a 4th generation language. I haven't really thought about that.
Don: So you're seeing this strictly as a non-DITA-referencing element
Chris: That's the main idea
Kris: Are there any concerns about moving this forward as a proposal?
Robert: As backwards compatibility goes this one is so trivial it shouldn't be a problem to change
Kris: If there are any problems they would be trivial. They'd be easy to fix in whatever other tool they develop
Stan: A process question: Is our intention for DITA 2.0 that all stage 1 proposals would be looked at first before going on to stage 2 development. Maybe other reference-y proposals will come. Should we wait and evaluate them against others?
Kris: In our volunteer capacity I don't see us queueing stage 1 proposals before we talk about stage 2
Robert: New things coming in may cause us to revevaluate other ones
Stan revised q: Would we *approve* any stage 1 proposals before moving on to discuss any stage 2? This might be something to clarify process-wise
Kris: We found in 1.3 that some proposals in stage 1 became amalgamated at stage 2 if there was overlap; I think this happened in several cases e.g. several proposals merged into branch filtering
Stan: this answers my question: it's possible to approve something into stage 2 before we've seen all stage 1s

Kris: Any concerns about moving this forward to stage 2?
Robert Will you move the card and assign it to Chris?
Robert: Done

6. New item: Some rambling thoughts about the domains attribute
https://lists.oasis-open.org/archives/dita/201701/msg00004.html (Anderson, 4 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00005.html (Thomas, 4 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00007.html (Anderson, 4 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00008.html (Kimber, 4 January 2017)
Robert: The blog post explains the history behind the domains attribute tokens -- what the syntax was and why -- and how they changed over time ... as we came up with new syntax to do everything we wanted to do
Syntax now is messy and complex, they're one of the things that make DITA look hard and complex
There were a whole bunch of theoretical ideas why they might be useful but most of them did not pan out
Bob: My pov is that the utility does not warrant the complexity. Specifically it's insufficient for describing what's going on with constraints; there's not enough syntax to facilitate automated processing
Robert: Plus making it complex enough to handle those cases would make it ridiculously difficult to understand and use
Kris: We've horrifically overcomplicated and overloaded domains over time, especially when we added weak and strong constraints, and later reusing a structural specialization as a domain
Robert: That's when it became impenetrable
Bob: When it jumped the shark
Robert: it's that tail we grew that we no longer need
Chris: The one thing that gives me pause is self-description of profiling attributes. Otherwise I'm completely up for it
Robert: That's why it's not a full-fledged proposal yet. I don't know what the right solution to that is yet.

[Michael joined the call]
Kris: Let's shift from item #6 to our discussion of Lightweight DITA and template based specialization

9. Continuing item: Lightweight DITA and template-based specialization -- WILL MOVE TO THIS AT 11:30 AM ET
https://lists.oasis-open.org/archives/dita/201701/msg00041.html (Eberlein, 19 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00043.html (Evia, 19 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00044.html (Hanna, 19 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00046.html (Kimber, 19 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00047.html (Anderson, 19 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00056.html (Priestley, 21 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00058.html (Eberlein, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00061.html (Kimber, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00062.html (Priestley, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00065.html (Kimber, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00066.html (Priestley, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00067.html (Kimber, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00068.html (Priestley, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00070.html (Kimber, 23 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00075.html (Grantham, 24 January 2017)
https://lists.oasis-open.org/archives/dita/201701/msg00076.html (Grantham, 24 January 2017)

[Short awkward silence, several jokes about who wants to go first.]
[Michael: I'm glad we had this little chat.]
Kris: Eliot raised some of the storngest concerns about it but he is not present. Michael, do you want to give the TC a brief overview of reasons for including template based specialization in an initial release of LwDITA?
May be simply a question of having a release of LwDITA that has some additional elements and attributes that could be used for it
Michael: The propoosal is to include a small set of elements and attributes that are intended for use to annotate a topic in such a way that you can derive from it a new content type, a new specialization
There are a couple of reasons why we wanted a tempate based approach
From day 1 we knew we wanted something to make it easier to do specialization in a lightweight manner
We went through a number of different approaches before settling on the template one
Why we want to do it: 1) in terms of what DITA is and what it means to be lightweight, I think our feeling was that if it's LwDITA then the "DITA" part of that needs to include specialization and if it's still going to be "lightweight", then if it's just for authoring and not specialization, then we're not addressing one of the chokepoints of full DITA. 2) In addition there are specific use cases around content-typing that are important to some of the adoption scenarios that we're focused on. The two main ones are marketing and learning-and-training. We've also looked (in less depth) at machine industry and at software documentation, both with SME authoring.
I'll focus on the marketing one: there's a huge appetite for what they call 'intelligent content', that appetite includes a set of best practice that align very well with DITA, e.g. focus on content types, chunks of content (topics), etc. Basically they have the concepts of maps and specializations, they just don't call it those names. A best practice is to do content typing on a per-project basis. E.g. setting up a new WebCMS, or a project within a WebCMS, you set up the content types. So that typing role is typically the role of a content strategist who is not a technical content person. The role of content strategist is an emerging powerful part of the marketing content ecosystem. Creating support within LwDITA around marketing use cases for content strategists to do lightweight specialization in a way that would be natural to them and appropriate to their needs (i.e. would feel like a natural extension of their work) was something we wanted to do.
Theer's one final principle: a cross use-case scenario, something else that LwDITA is targeting, to be a bridge across islands of diffenerent content types. The ability for people to have a way to express a content type that is format independent, not just an XML schema but "here's an _expression_ of the content type I'm going to annotate and from that create the tools I need to work in that format, and if someone else is working with that content type I should be able to show them my topic and have them create their own tools". The subject of that topic being essentially the semantics of the topic type.
The principles are sharing a model across tool chains, also the topic is annotated not only for model intent but also labeling intention. There are all sorts of artifacts that could be single-sourced from a topic.

Kris: from last week's call, some of the concerns tthat some people raised:
- template-based specialization has nothing that pertains specifically to LwDITA, there's very little that couldn't be done with a namespace, it's great tool but maybe it shouldn't be part of a standard
- specialization is probably going to apply only to LwDITA in an XML format, difficult to figure out how it will work in HTML or Markdown
- Eliot was saying that a mechanism needs to exist but doesn't need to be part of a standard, we shouldn't expend time on making it part of the standard
- Maybe it should be a companion standard, interchanges of models vs interchange of content

Chris: I don't think anyone is arguing against the usefulness of template based authoring
I think the argument is about its inclusion in the standard
There's nothing else in LwDITA that is blocked by the presentce or absence of template-based specialization
We can still have a simplified content model, simplified specialization mechanisms (even without the mechanics), etc.
Having a template-based specialization mechanism brings forth all these advantages, but makes it uncomfortable not least because OASIS cannot release tools but only specifications

Michael: Start with the end game, in terms of nothing being blocked by its presence or absence and OASIS can't release tools. If we decide we want to split out the standard I think that's a reasonable option.
I want to push back on the idea that the template is tied to tools. We've got stuff like the filtering/metadata attributes in DITA, we've got conrefs that have no _expression_ witout tooling to support. With learning and training we have expressions of assessments etc. that are meaningless without tool support. There are very few cases in which XML is useful without tooling.
Chris: You're right that without tools the XML is meaningless, but all of those features you just listed have to do around enabling a certain class of tools around a certain class of use cases around publishing. This is a use case that is outside the traditional set of use cases that we gear the markup towards. That makes having the grammar definitions mixed in with the content semanticizing and certain levels of format description seems unatural.
Michael: To some degree what we have here is self-fulfilling prophecy. Content type definition is hard to do so it's not done by writers. Marketing is a specific example, it includes a different role of content architect. Web CMS that target the marketing arena have custom tools to make it easier for nonarchitects to create 
In some Web CMS it is literally an authoring environment
In the tech doc realm it's true but might have been less true before DITA standardized some of this stuff. That feeling to us is learned not innate.
Bob: In some ways we have ventured into content modeling anyway. Supporting it just because we have standards-based specialization.
Michael: Good point; we tell people how to specialize already
Mark: And there was no way to do it before
Kris: All of us care and would like to see that specialization is easier. We'd like interchange of models to be easier. The question is how do we do it. Some of this needs to be written down.
Carlos: It is written down, we should have more notes available in the committee very shortly
Robert: One issue I expressed to Michael is in my view the purpose of the spec was interchange, I get that, I feel the two are two separate beasts, in trying to do both with one standard we'll lose track of one or both purposes.
I'm not opposed to having a separate standard for the interchange model
Michael: A counterpoint still today: the #1 content application that users are exposed to (at a professional level) is Word. We are following something very similar to the Word model here. 
Robert: Part of what's informing me here is experience with standards themselves (DITA). Having seen over time editing 1.2 and 1.3 that trying to do so many things with one standard, using DITA to achieve new ends that weren't there to begin with, we end up overcomplicating things and overburdening things, and the result ends up less focused.
Having separate standards allows you to really focus on what you want to do.
Michael: I don't feel strongly either way about splitting, I'm happy to take the splitting path if that is the path forward.
I would still like to see if we can get them in the same time-frame but making two deliverables is a reasonable step.
My concern is all the concerns I'm hearing about doing template-based specialization at all.
Chris: If we had separate standards, perhaps we could make the template-base specialization also for full DITA.
Michael: The hesitation I have is that LwDITA at least gives us a smaller starting point, fewer permutations to consider. I'm fine with it being extended to full DITA but would like to get a first release that is at least scoped to LwDITA.
Chris: If you can't do everything you can do in RNG, that's fine with me.
Michael: We can talk about that. I want to be sure we get a template based specialization out at the same time as LwDITA. Again for scenarios such as the marketing team.

Kris: We are at the top of the hour, thanks Michael and everybody for calling in. Michael we may need you at another meeting sometime. Everyone please pick up the conversation on the list.

Meeting closed at 9am Pacific time.
        
-- Mr. Tom Magliery

Document Name: DITA TC Meeting Minutes 31 January 2017

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Mr. Tom Magliery
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2017-02-06 12:01:54