OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: LightWeight DITA Committee Note Meeting Minutes for 14 Dec 2016

LightWeight DITA Committee Note Meeting Minutes
Wednesday, 14 December 2016
Recorded by Keith Schengili-Roberts

Attendees: Carlos Evia, Kris Eberlein, Mark Giffin, Robert Anderson, Nancy Harrison, Michael Priestley, Eliot Kimber, Keith Schengili-Roberts, Stan Doherty

The point of the meeting was to go through each section of the draft document and comment.

Nancy asked whether the “Simplified specialization mechanism” should come immediately after “Simplified model”; Michael pointed out that the “Simplified model” sets things up for the non-XML versions of LwDITA which is the chapter that comes in between the two

General comment from Kris that the into section is very light at the moment and needs to be expanded.

Kris mentioned that we need to be careful when talking about conformance and compatibility.
- HDITA and XDITA are designed to be compatible with each other
- MDITA is a compatible subset

Michael pointed out that this is a Committee Note and not a Specification, so conformance is not required at this stage.

Stan asked why there is no mention of ability to do LwDITA in a Word-compatible format. Michael responded that while this can be done but at the moment we do not have the resources/expertise to make this happen. Michael suggested we add a statement that we welcome outside resources who may be able to help/contribute.

Kris: need to note that there are new elements in LwDITA that do not conform to DITA 1.3.

Eliot: suggested we use the following statement: “LwDITA should be a conforming application of DITA 1.3”.

Michael added that: “Any LwDITA topic should be a valid full DITA topic.”

The DITA standard does not “care” about conformance outside of XML / DITA specification; should expect that it could be mapped between the versions; all of the flavours should be able to play together.

=Relationship of LwDITA to Full DITA 1.3=
Keith asked if we should designate this as LwDITA 1.0 and that it maps explicitly (excepting new elements/attributes that may be included) to DITA 1.3. There is currently no statement to this effect in the draft document. Other suggestions included calling it a “Profile” version using a different numbering scheme, or making it a point version, like “LwDITA 0.1”.

There is currently no content in this section. Carlos explained that material from here has been moved to section 5 (“Lightweight DITA specialization model”).

General agreement that this section should be a conceptual overview; chapter 5 needs to have more technical details and content.

Kris emphasized that it should not be expected that this Committee Note will allow people to do specializations or exactly how to write LwDITA; it is more to announce the intention behind the ideas of LwDITA.

Eliot: suggested replacing: “Lightweight DITA does not permit mixed content” as it is inaccurate. Michael suggested: “Lightweight does not permit mixed content to contain blocks or block elements”. We either need to avoid the term “mixed content” or use it accurately.

It was pointed out that content that is written using the XDITA version of LwDITA can be verified, but there is no equivalent verification mechanism for HDITA. So it is possible to write HDITA content that is not valid LwDITA. It is simply HTML5.

Nancy suggested using: “A combination of block and text content within a single element”.

It was noticed that simpletable is not mentioned as an element that can be used in the Content Reference list.

Robert suggested that instead of saying “The conref mechanism…” it should say instead “The content reference mechanism…”.

Kris: asked for a short explanation as to why the scenarios listed here are the ones that were selected; just a single paragraph ought to do to explain why the scenarios are considered to be representative if not fully comprehensive.

Michael added that the fundamental design of LwDITA started with a minimum set and then through workshopping added in elements that are the most fundamental for basic reuse.

Michael also suggested that we make an explicit statement to the effect that when it comes to LwDITA reuse, for blocks use a conref strategy, and for phrases use keys. Also state that there are no conkeyrefs in LwDITA.

Kris suggested that this should be split into two separate sections: one for elements and one for attributes.

Eliot expressed a general concern about using “mode” when it comes to authoring, because it may seem like we are suggesting a particular tool. “Authoring formats” or “authoring method” would be a better way to phrase it.

Kris asked that the scenarios be made more robust.

Stan suggested that it should be mentioned that each of the LwDITA variants (XDITA, HDITA and LDITA), should be considered as being one part of a suite, and that for different scenarios the other LwDITA variants may be more applicable.

Nancy mentioned that at the moment “the implication is that everything will work in parallel, but right now specialization only applies to only one of the LwDITA formats (XDITA)”.

Carlos: specialization may end up being a “LwDITA 2.0” thing. This was an idea supported by Kris and Robert. Robert also suggested that a separate, subsequent Committee Note could also be devised that talks about specialization for LwDITA instead of putting it into the initial LwDITA specification.

Carlos stated that he is currently leaning towards keeping specialization out of an initial version of and said that would talk to Michael about it further (Michael had to leave this meeting mid-way). Robert added that conversely if specialization was left in it would definitely receive more comments. Kris said that by removing specialization from the initial version of LwDITA that it would result in a much smaller scope of work for the specification, and in general she is in favor of things that would make this come about more quickly. Nancy concurred, saying that appears to need so much more work than the rest of the document, and is likely to hold it back if it is retained.

Kris pointed out that this section is currently lacking detail. Much of the information on this exists only in Michael and Tim’s heads.

To the question of whether we can mention specific software vendors in this document, Robert responded by saying that Committee Notes are considered to be “point in time” documents, so mentioning specific vendors or tools is okay. He concluded by saying that: “tools will have to be built on the specification, and this is not the specification”.

Kris suggested a structure for this: introduction, brief overview, then take a template topic and walk people through how it was created, what the specific attributes are in it that are the hooks for creating new structure, and then show what comes out from it.

Meeting concluded at 5:32pm EST.




Keith Schengili-Roberts
Market Researcher and DITA Evangelist
825 Querbes, Suite 200, Montréal, Québec, Canada, H2V 3X1
tel  + 1 514 279-4942  /  toll free + 1 877 279-4942 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]