Groups - DITA TC Meeting Minutes 31 January 2017 uploaded

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