| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 22 March 2016 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 23 Mar 2016 12:27:06 -0700 (PDT)
1. Kris will send out mail to TC list with link to the conference dinner wiki page,
2. Tom will add Scott's proposal on fixing missing shortdesc to the errata list.
3. Nancy will send out meeting minutes by Weds.
4. Kris will complete the OASIS forms for creating the Open DITA repository for Lightweight DITA
5. Tom will put up a wiki page to collect ideas for new dita.xml.org.
Minutes of the OASIS DITA TC
Tuesday, 22 March 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
Regrets: David Helfinstine; Keith Schengli-Roberts, Stan Doherty
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201603/msg00013.html (Nancy Harrison, for 15 March 2016)
Proposed by Kris, seconded by Bob, approved by TC
1. Action items
23 February 2016
Tom to add typo to 1.3 errata list (Completed)
Kris to look at OASIS process around errata
Kris to add agenda item for next week on potential topics for dita.xml.org around community best practices and things we want to engage with larger community on. will send same thing to DITA TC members to get us thinking about that item. (Completed)
All TC members need to review OASIS guidelines for writing conformance clauses.
Kris will find out what we need to do about opening an OASIS admin request to get an open source repository set up for Eliot's tooling project.
Kris; all 23 Feb. items completed
15 March 2016:
Tom: Will ask Chet Ensign about whether OASIS does (or could) run Google Analystics on DITA spec pages
Kris: Draft statement asking people to link to official OASIS DITA 1.3 pages for TC consideration (to be used at CMS/DITA NA and evangelized on dita-users)
Kris: Ask Chet Ensign whether we could add additional metadata to the OASIS DITA 1.3 spec pages
Kris; 15 March items not done yet
New members: Welcome Deb Bissantz and Maria Essig from Healthwise!
DITA TC dinner:
Monday evening, 4 April 2016, in Reston, VA
Sign-up ASAP at SignUpForApril2016Dinner (link)
ActionItem: Kris will send out mail to TC list with link to the conference dinner wiki page,
3. Continuing item: Tentative DITA TC agenda for 2016:
Reflections on DITA 1.0-1.3
Continued work on TAB comments:
Normative and non-normative wording
Hyperlinks for all element and attribute mentions
Conformance statement (will handle as part of item below)
Focus on conformance statement and new OASIS guidelines
DITA 2.0 planning
DITA 1.3 errata planning
OASIS open repositories
Interoperability demo, perhaps at tcworld 2016
Upgrade DITA-OT plug-ins to work with DITA-OT 2.2.2 or later
[just on list to track - no action]
4. New item: DITA 1.3 Spec errata: Missing shortdesc
https://lists.oasis-open.org/archives/dita/201603/msg00007.html (Hudson, 15 March 2016)
- Scott; I just found a missing shortdesc for a topic in the langref; it's the parent topic for all the troubleshooting elements.
- Kris; we'll move this to our list of 1.3 errata.
- Tom; I've been adding things to the list; I can add this too.
- Scott; in my mail, I proposed a shortdesc for the missing item.
ActionItem: Tom will add Scott's proposal to the errata list.
5. New item: TC approval for Lightweight DITA open repository
https://lists.oasis-open.org/archives/dita/201603/msg00008.html (Day, 21 March 2016)
Scroll down until you reach "Purpose statement"
- Kris; we need to approve this, initial maintainers are Don, Michael, Mark Giffin, Carlos Evia; see mail for details
- Kris; moved to approve, Michael 2nded, no objections, approved by TC.
ActionItem; Nancy will send out minutes by Weds., and Kris will complete the OASIS forms for creating the Open DITA repository for Lightweight DITA.
6. New item: Topics for discussion on dita.xml.org
https://lists.oasis-open.org/archives/dita/201603/msg00016.html (Eberlein, 23 March 2016)
- Kris; as members of TC in conjunction with Adoption TC, we're DITA thought leaders; we need to start and steer discussion on the site, so let's talk about it. what should we seed site with?
- Tom; should we assign someone to collect the list., wiki page maybe?
- Kris; a wiki page would be the best
- Don; if they go into the minutes, we can glean them for that.
- Tom; but we might have ideas in between; i'll put up the page
- Kris; and the focus area page should point to that wiki page.
ActionItem; Tom will put up a wiki page to collect ideas for this.
- Don; what about a slogan? we need a slogan for DITA / 1.3; we want people to look at DITA in an open-ended way, not just thru the perspective of tech writing, and a good slogan could help with that.
- Kris; would be great if we were lucky enough to have someone write a piece about DITA and various vertical industries, e.g., education, medical devices, health industries, etc. These are areas we want people to be thinking of DITA for.
- Scott; but the site is also a space for best practices, things we recommend, complementary technologies, e.g. Schematron.
- Kris; ActionItem: for 1.3 errata, Kris will set up a schematron rule to ensure all our DITA topics have shortdesc. And best practices around shortdesc can always be dicussed fruitfully on the site.
- Kris; I encourage folks to think about this as your own personal wish list; try to put our fingers on what are the most important pain points, get folks to start working on our content.
- Joann; will these be articles that are vetted by TC?
- Kris; this will be a curated site.
- Joann; but it will be different from Adoption TC white papers. So will we do the same kind of review for this that white papers get, which is quite extensive? What will be the role of curating?
- Don; I'm hearing that what we need to do is create direction and velocity for the evolution of the standard. The goal for the site is to talk aoout DITA in a way that get others interested enough to add their own input as well. It's not a formal document, out there to set direction.
- Joann, but what's the relationship of this TC to the content on the site? Does curating mean we're going to monitor the content? awfully big job...
- Don; but first writers will use our own tools.
- Michael; don't see this TC doing real monitoring of the site content. I don't think every article has to be curated, e.g., blogs put out by known DITA experts wouldn't be curated. What we have on this call is a bunch of DITA SMEs, we need to trust ourselves. These would not be formal white papers; the site doesn't replace Adoption TC in terms of white papers, but we need to use the expertise of this TC and get content flowing.
- Joann; so we need to articulate this and make it clear.
- Kris; so everyone on TC, imagine what you think of as good content, and get people to return to a re-vitalized DITA XML site. The more of us that do this, the better.
[comment from Margaret from ??]; we're still on 1.1, can think of topics related to 1.1,
- Kris; you bring up a good point; many folks are still using 1.1, or even 1.0. not 1.2/1.3. Why? what works for them? what would help them?
- Don; I have an 1.1 ditamaps tool equivalent for RSSC. So it's a use case that doesn't have any user requirements for DITA, and so there's never been a reason to upgrade past 1.1. Goal is to use right the tool for right kind of application.
7. Continuing item: Spec Clarification Issue: Characters Allowed in Key and Key Scope Names
https://lists.oasis-open.org/archives/dita/201602/msg00049.html (Eliot Kimber, 26 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00050.html (Scott Hudson, 26 February 2016)
- Eliot gave overview; both 1.2 aand 1.3 just say key scope can use characters legal in an URI; not actually precise, because the characters allowed in a URI differ from the set of characters allowed in different parts of a URI. So we need to clarify the rules. Jarno was asking questions, should we use XML NMTOKENs like the XML spec? We need to think about this issue and try to decide on the right answer; I think the best way is to use XML name tokens, would be consistent with XML.
- Scott; do we really need to allow @ sign and = sign? I don't think so...
- Eliot; probably not.... But we don't want to have things that are currently allowed by the spec become disallowed; the chance that folks are using '@' or '=' are pretty remote. For actual key-matching, it's just string matching, Joarno used pretty restrictivve rules.
- Kris; for Oxygen, who discovered this, it wasn't customers who found it, it was testers who were using diacritical marks that didn't work. There are 2 things to consider:
1. what do we want to say, in 1.2 and 1.3? And having already isseued the specs for those releases, what do we say now?
2. when and how do we want to address this? We definitiely need to document it in the errata and fix it in 2.0, but we can also provide clarification in an article in dita.xml.org? How quickly do we need to provide info on this to the community
- Eliot; this can't fall into errata, it's too big a deal, but given ambiguity of current language, we can provide some guidance.
- Robert; is it really ambiguous? I thought Jarno used a precise reading of our text.
but term in 'allowed in' isn't clear. If you encode a char, you can put anything in, it's only uncoded characters that give the problem, but URI spec says anything else requires being encoded within legal characters.
- Eliot; the real question is; what did we intend?
- Robert; yes, that may be, but what is precise is the limitation.
- Eliot; so the question is; do we allow only characters allowed in URI stream, or are we including characters that must be escaped? if the latter, any character allowed thru excaping, we can clarify; otherwise, Jarno is right.
- Kris; But we have to address both issues; 'what was our original intent?' as well as 'what does the the spec state'? Robert says it's precise but not clear; Eliot says it's neither precise nor clear.
- Eliot; in XML, any character can be included in an XML document, but in a URI, some characters needs to be escaped. There's no reason for any character in a key name to be escaped.
- Don; when you paste a URI with unicode characters into a URI, the browser itself encodes them. Can't we go with that?
- Eliot; but we're not really talking about URIs, but keynames, and they're not exposed to browsers.
- Robert; there's no reason to escape things, except that we tied it to another standard, URI, that requires escaping them. It wasn't good, but it's what we specified.
- Eliot; but we didn't specify how to escape it.
- Robert; but because we explicitly noted the URI spec, we implied that for those higher value ASCII characters, you have to escape them.
- Kris; any other TC members who want to chime in on this.
- Chris; Eliot's point is right; it's not what we wanted, but it's what we said. We can loosen the language, but we can't make it stricter. I think it's too big a change to treat as errata.
- Bob; is there any way we could put out a clarification? Saying that there's intent to make it not required going forward?
- Michael; the current situation may be ridiculous, but we said it. So to loosen it won't be 'clarification'; it will be a change. We might as well remove mention of the URI spec from that paragraph.
- Kris; I'm concerned with us telling folks that 'we made a mistake in the spec, just disregard it...'
- Eliot; or maybe it's not worth doing; it took 5 years [since keys came out in 1.2] before someone noticed it.
- Robert; shall we just say that we're going to change it.?
- Eliot; yeah, to anything allowed by XML spec for NMtoken.
- Robert; so we might want to just say we're going to expand it to everything allowed in NMtoken.
[need to discuss dots, but a topic for another time]
- Chris; I think we need to decide what we're going to use going forward, then let folks know.
[Eliot and Robert disagree on this]
[continued to next week]
11:59 PM ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]