dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 30 March 2021 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Mon, 5 Apr 2021 15:25:45 +0000 (UTC)
Submitter's message
ActionItem:
1. Kris will ping Eric wrt review of Eliot's copy-to proposal.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 30 March 2021
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Kris Eberlein, Nancy Harrison, Scott Hudson, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens, Frank Wegmann, Jim Tivy, Dana Aubin
Business
========
1. Roll call
Regrets: Carlos Evia, Stan Doherty, Gershon Joseph
2. Approve minutes from previous business meeting:
02 March 2021
https://lists.oasis-open.org/archives/dita/202103/msg00046.html (Lawson, 30 March 2021)
Moved by Kris, 2nd by Scott, aprroved by TC
16 March 2021
https://lists.oasis-open.org/archives/dita/202103/msg00047.html (Harrison, 30 March 2021)
Moved by Kris, 2nd by Frank, aprroved by TC
3. Announcements
none
4. Action items
[no updates; see agenda for complete list]
5. Check-in: How are people doing in this difficult time? How is your state/country doing?
- Keith; just to watch out for, an awful new book, theoretically on DITA, available on Amazon. Appears to be cobble together by machine from other machine-written books about programming. Title says it's about how to write using DITA, but there's nothing about DITA in it. Author of record is Frank Merwin, caution clients and anyone interested in DITA not to waste time or money on it.
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
Stage three
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
15 March 2021: Proposal to reviewers (Anderson, Sirois)
?: Initial discussion by TC
?: TC vote
- Eliot; no feedback from reviewers (Eric, Robert) yet.
- Kris; when can you guys get it back?
- Robert; will do it this week
- Kris; I'll ping Eric and ask him to get it to you by end of this week, next week you can give us an up[dated ETA
- Eliot; OK
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
(./) 25 August 2020: Early draft feedback received from all reviewers
? : Submit to reviewers
? 2021: Initial TC discussion
? 2021: Vote by TC
- Kris; this is on agenda today, our discussion should give us a sense of progress
7. What aspect of DITA 2.0 is most appealing to you?
https://lists.oasis-open.org/archives/dita/202103/msg00017.html (Eberlein, 16 March 2021)
[no updates today]
8. Shall we do a DITA 2.0 Webinar for vendors?
https://lists.oasis-open.org/archives/dita/202103/msg00018.html (Eberlein, 16 March 2021)
Brainstorm of companies that we should encourage to attend
Brainstorm of roles at companies who should attend
[no updates today]
9. DITA 2.0 stage three proposals
Vote
None
Initial discussion
None
Continuing discussion
None
Early feedback
#15, "Changes to specialization rules"
https://lists.oasis-open.org/archives/dita/202103/msg00045.html (Eberlein, 30 March 2021)
- Kris; I want to get check from TC on using term 'expansion module'.
- Robert; I like the grouping of document configuration vs element type configuration.
- Nancy; I like the change as well, just to note, we'll need to put this in 2.0 migration guide as a new way to think about configuration.
- Eliot; document configuration is everything you do in shells. I think expansion is a good term; my concern is that constraints and expansion are not separate modules; they'd be done in the same module; the conceptual distinction is clear, but might present possible onvfusion about the type of module you have, whether you're doing constraint or expansion.
Scott; what about using a single module name that would cover constraints and expansion?
- Kris; it took users a long time to wrap their minds about constraints; I want to continue to use that term so as to not confuse them further. I want to introduce 'expansion modiules' to cover this other use. We did agree in an earlier call that we were confortable with the term 'element-type configuration'; the question is what we call the new @ version, and I'm suggesting 'expansion'. Eliot; I understand your point, we'll need to clarify it.
- Eliot; so we need a single term for the module type. Does 'element-type configuration module' suit that?
- Chris; the feedback I got strongly felt we couldn't drop concept of constraints; so the term we use is important.
- Eliot; no we'll no longer be calling them constraint modules, now they'll be element-configuration modules?
- Kris; you'd like to have just one name for module; I want to prototype it as if there's 2 types of e-c modules so we can completely suss out if there are any differences in rules and best practices with them; I don't want to mush them together if that will lead us to contorted language.
- Eliot; not sure how that would be.
- Kris; given the implementation Chris had proposed, there are some differences, e.g., slightly different names for entities, also you can create multiple expansion modules that target adding @s to an element, and incorporate multiple such modules into a DTD; but for a constraint module, all the constraints have to be aggregated in one module.
- Eliot; but that's the difference between @s and elements; for element content module, constraint and expansion have same rules; for @s they're different.
- Chris; also, constraints can be used to remove elements from domains, but there'sno way to add to a domain without creating a new domain.
- Eliot; expansion is about adjusting content models and @ lists, constraints is about vocabulary.
- Chris; these concepts are intricately related, and fundamentally the same thing, but there are a few subtle differences so it's not clear-cut. Kris's draft treats them as related concepts.
- Eliot; we need to keep 3 things straight:
1. the concept of constraint is different from concept of expansion.
2. those 2 concepts are distinct from semantics of how you implement them.
3. the first 2 items are distinct from basic concept of e-c module; the e-c is the place where you do them, and these are what you do with the module, and these are the things you do with the syntactics.
- Kris; what I really want to test today is the use of word 'expansion'.
- Eliot; I'm good with that, seems the best we had so far.
- Kris; I wanted to retain parellelism as much as possible.
- Jim; seems like a good term, I agree with Eliot wrt specialization having 2 levels;
1. intent and metamodel,
2, using syntax (DTD/RNG) to implement intent and metamodel; separating those 2 things is very useful.
- Kris; anyone with concerns or objections?
- Frank; not a concern, but you also use 'extension' in the middle of the text? do you meen expansion in that context.
- Kris; I carefully did not use 'expansion' to apply to 'mix-ins'; I use extension to cover broad ways in which people can work with DITA models to meet their own configuration requirements. Because we had used extension as that broad umbrella term.
- Frank; so extension also covers constraints?
- Kris; yes, it does
- Zoe; in the 2nd sentence 'constraints and extensions' should be 'constraints and expansions.'
- Kris; oh, a typo...
- Zoe; is there a glossary in the spec?
- Kris; there's not, and there should be. it's been on my wish list since I became a spec editor. It would be good to have a rudimentary glossary. Anyone interested in working on one?
- Zoe; I would be.
- Nancy; I would be also.
- Deb; Stan, Scott and I went thru the spec and pulled out some terms as a side project....
- Scott; I don't know where we got to with that.
- Kris; Scott, can you post what you have to the list? I will post a term list I've been gathering for a decade. We all care very much about how we define things; lack of a glossary has caused a lot of time, and a lot of disagreement. We may be able to start but not finalize for 2.0, but it would be good to work on it.
- Kris; I think we've got agreement with 'expansion' vs 'mix-ins,' I will go forward with this in spec; then we'll need to do review and look at what it looks like. Specifically, do we need to aggregate these things more completely; i.e. treat the modules as one type vs. constraint and expansion modules? I didn't want to move in that direction until I'd prototyped both to identify similarites and differences, and how to talk about them cogently in the spec. The spec isn't a tutorial, it's for DITA architects. Because we've already had an idea of constraints, we want to figure out best way to explain this concept. We've acknowledged that we've encouraged people to think in one way so far, and the spec isn't just for brand new DITA architects, we need to accommodate folks who've been working with the current model. We don't want to force them to reauthor them as e-c modules. we want to consider our user base.
- Kris; any other reviewers? Chris and Eliot currently.
[none]
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]