dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 6 September 2016 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 12 Sep 2016 09:06:08 -0700 (PDT)
Submitter's message
Action Items:
1. Kris will contact OASIS about responding to ur 1.3 errata review request
2. All TC members: think about 2.0 and ideas for re-org of spec.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 6 September 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Regrets: Deb Bissantz, Stan Doherty, Maria Esrig, Joe Storbeck
Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201608/msg00130.html (Nancy Harrison, 30 August 2016)
Proposed by Kris, seconded by Scott, approved by TC
Business
========
1. Action items
2 August 2016:
Robert: Produce initial draft of "DITA and DITA-OT" committee note
Robert; working on it, should have something by next week
Kris: Schedule meeting for small group working on "Upgrading" committee note (IN PROGRESS)
23 August 2016:
Joe: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN
30 August 2016:
Nancy: Post minutes ASAP (COMPLETED)
Kris: Open TC admin ticket for errata 01 public review (COMPLETED)
Eric: Review spec and suggest changes for issue raised by France Baril
Eric; will look at it for next week
Kris: Begin organizing subject scheme education for TC (IN PROGRESS)
6 September 2016
Revise subject scheme example topic pulled from errata 01
Kris; in progress
2. Announcements:
New DITA TC members: None
3. Continuing item: DITA 1.3 errata
https://wiki.oasis-open.org/dita/DITA%201.3%20Errata
DITA-1.3-errata-schedule
Kris; currently tracking a week behind; if we were on time, OASIS would have finished preparing for public review. but we don't even have a confirmation from them that our request was received, I'll will prod them on that.
Eliot; i reviewed it last week and provided comments
Kris; did you find anything besides your one comment?
Eliot; no, seemed good
ActionItem: Kris will contact OASIS about responding to ur 1.3 errata review request
4. Continuing item: Issue with leaningObjectMap content model
https://lists.oasis-open.org/archives/dita/201608/msg00068.html (Sirois, 17 August 2016)
https://lists.oasis-open.org/archives/dita/201608/msg00069.html (Eberlein, 17 August 2016)
[hold for next week, when Eric will have had a chance to look at this]
5. Continuing item: Work on committee notes
Update to "Why Three Editions"
"Upgrading to a new version of DITA"
"DITA the standard versus DITA Open Toolkit"
[see above ubder 'Action Items']
6. Continuing item: DITA 2.0 discussion
None
- opo
7. New item: related links from archSpec to langRef (and vice versa)
https://lists.oasis-open.org/archives/dita/201608/msg00003.html (Eberlein, 2 August 2016)
- Kris; we've been asked for some related links, since it's hard to work between the two sections. for 1.1 and 1.2, we had separate langrefs and archspecs. For 1.3 we combined them and tried to get rid of duplication. But it's hard to use. What do we want for 2.0?
- Eliot; if we remove L&T, that might get us to a place where we can have a single package; think that's one of the factors.
- Robert; I think separating L&T is a given.
- Amber; folks who use L&T are using it for very specific purpose.
- Robert; L&T takes up almost half the spec; if you're considering just the base package, are there ways we could reorganize that for 2.0 to make it more usable?
- Keith; perhaps leaving a slot open for things that can feed into Lightweight DITA (LD), Markdown, JSON, etc
- Robert; in the language we use to describe elements, we should be focusing on descriptions rather than content models.
- Kris; one core part of 2.0 is needing to, prior to its release, look at langref topics for elements that are in both DITA and LD, and reworking shortdesc and content, so there's solid alignment between DITA and LD.
- Robert; langref topics today are somewhat inconsistent in style, we really want to share content; want to define elements so that it's easier to understand them for
non-markup-language weenies. The actual meaning of each element needs to be same for both DITA and LD specs.
- Kris; goes back to earlier point; 2.0 is an opportunity to remove deprecated elements, fix bad architectural choices. edit and re-design the spec.
- Keith; do we have a design goal for 2.0? besides 're-visit and fix things? are there things we're looking to do fundamentally diffferently? What is new 2.0-ish?
- Kris; the main part is enabling breakage of backwards compatibility requirements, so we can do these re-designs. There's less radical new changes, and more to clean up and simplify current architecture.
- Robert; my goal is simplification, plus moving L&T out, since rewriting 'everything' makes more sense if 'everything' doesn't include L&T.
- Kris; one stated goal is alignment of DITA with LD, plus optimization of less usable parts of the architecture, producing more targeted editions.
- Tom; when we start removing L&T, are there other parts we're taking out? And what does 'taking out' mean? also, what to name packages we produced, and problems related to OASIS.
- Nancy; so what will we do with tech content?
- Chris; my question too.
- Kris; We're looking at also separating techcontent out. and what does that mean?
- Amber; and we need to work out difference between 'standard' and what's on sourceforge. what do most people use? and what do we want to support them using? One way to do this is to look at the spec, what are we really supporting, and what isn't supported, but is available?
- Dawn; if L&T goes out as 'unsupported', it loses credibility. clients don't want to use it.
- Robert; is the reputation as a 'supported' specialization really warranted? not a lot of people working on it.
- Eliot; still needs to be some group that maintains it, either TC, SC, open-source project, or something else. The community always seems to say that if it's not officially supported by the TC, it's not safe to use.
- Nancy; needs someone to step up and support it.
- Eliot; well, Amber and myself both use it.
- Kris; got to think of a couple of things. original idea of DITA was specializations to be created by many people. most specializations out there are not supported and no one maintains them (see ones out on SF). This is a large general problem, not sufficiently addressed by TC, Adoption TC, or DITA-OT project.
- Robert; also, saying that moving L&T out of 2.0 means it's unsupported, may not be the case.
- Eliot; if a spec has value, the person who values them can update them. it's only 1.3 that we want to really keep stable. It's really a user community, there's not much the TC can do but set expectations in how we package our output.
- Robert; We started out with re-org of spec itself, just thinking of base, any ideas for re-org? In 1.0 and 1.1, separate langref adn spec; should we go there again?
- Eliot; I don't see any value in publishing archspec without langref.
- Scott; we need to look at our audience; archspec is for implementors and tool designers; langref is for authors and end users. Many folks are just referencing langref
- Keith; if we're moving away from an xml-based way of describing things, it might be good to separate them.
- Robert; or maybe the opposite, we may want the spec to be more abstract, if the element descriptions are more concrete.
- Kris; we may be in the dark until the LD spec is available.
- Robert; whether together or separate, we're talking about the OASIS version. vendors can do what they want to separate them. We only control what people see when they go to OASIS.
- Kris; and please think broadly; don't just think about arch spec and langref; that's what we have, not necessarily everything we need.
- Don; I'm wondering whether DITA 2.0 should try to make use of recent changes to the XSL spec itself. There's a mechanism for specialization formally recognized as a concept in XSL 3.0.
- Eliot; not really; there's a way to map things to attribute values. but it doesn't affect specialization.
- Robert; I have lots of ideas, based on working with 1.3;. I'd like to see greater separation between element descriptions and @s, where do you go to find defs of @'s? People want to look up elements based on what @s they use, instead fo other way around.
- Eliot; having a separate definition of @'s is the way I've always done specs.
- Robert; maybe we can use the method HTML uses, separating definitions
- Nancy; we went a bit of that way in 1.3
- Robert; yes. but we need to keep going. We have some @'s that have one meaning for many elements, but completely different for others, like @type on links and 'note'.
- Eliot; question is whether we really should have @type on links at all
- Robert; agreed
- Kris; lots of duplication in arch spec and lang ref, very problematic; we've got to figure out a good way of avoiding duplication and contradictions. It was really difficult to review everything about subject scheme.
- Chris; we are about both a grammar and a processing implementation, unlike things like DocBook or TEI. Maybe breaking it down into a processing guide and a grammar guide would be useful
- Kris; very good idea, maybe a 3rd component, a 'design' audience
- Eliot; right, a customizer's guide.
- Kris; 'design' in the aurchitectural sense, designing extended DITA vocabularies
- Robert; I like that too
- Kris; and let's not leave out the end user audience, for 'using' and writing with DITA.
- Dawn; are we writing a spec/reference or a user how to? I always think of it as a spec.
- Nancy; what about third-party books being written
- Kris; we need to stick with the spec; we may put out white papers, but we need to focus on core. Some of our materials will be used to write more adoption materials; what should be DITA/adoption? It goes back to the discussion on whether it should be a separate committee.
- Robert; just like the spec, where it's hard to decide what's spec and whats langref. My #1 goal is for a processing and grammar spec, It has to be laying out rules. Even though the goal is to make it as readable as possible, the core goal is to lay out rules.
- Kris; and so people can design specializations of the architecture and use them. If we call it a langref or not, we still need definitions that clearly lay out semantics, especially as LD comes out and we need to align with it. Our lang defs should be used by everyone,
-----------------
Other:
Kris; if you have an action item, please work on them. please everyone please keep thinking about how we can update written material for 2.0? especially if we thinking Oou of the box. and how can we go forward with making more modular work products?
11:59 ET Close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]