dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 30 May 2017 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Tue, 6 Jun 2017 04:02:22 -0700 (PDT)
Submitter's message
ActionItem:
1. Robert will fix the wrong version number he no ticed in the RNG files and note it in Errata 02 doc.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 30 May 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Business
========
1. Roll call
Regrets: Carsten Brennecke
2. Approve minutes from business meeting on 16 May 2017:
https://lists.oasis-open.org/archives/dita/201705/msg00059.html (Nancy Harrison, posted 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00091.html (Corrections from Joe Pairman, 30 May 2017)
moved by Kris, 2nded by Scott, approved by TC
3. Announcements:
New TC members: None
4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
04 April 2017
All TC members consider what they want to see on the new DITA.xml.org site for the DITA TC
09 May 2016
Eliot: Compare links provided by Paul Knight with those listed in the errata 02 documents at https://lists.oasis-open.org/archives/dita/201705/msg00036.html
23 May 2016
Kris: Respond to Ian B. with link to minutes (Completed)
Kris and Robert: Review Adoption TC white paper: "DITA 1.3 A to Z" (Completed)
Nancy and Alan: Review Adoption TC white paper: "DITA 1.3 A to Z"
Alan; donem, Nancy in process, will be done today
Robert: Errata 02: Correct the content model appendix topics for ditavalmeta / ditavalref for the same.
Robert; done
Robert: Errata 02: Correct the ditavalmeta section so the example link goes DIRECTLY to the example.
Robert; done
5. Update from Lightweight DITA subcommittee
Update from co-chair Carlos Evia
Suggested schedule for LwDITA work this summer
https://lists.oasis-open.org/archives/dita/201705/msg00084.html (Eberlein, 28 May 2017)
Carlos; SC has been working quite hard, has what we thinks as a very solid and complete draft as a Committee Note (CN); final meeting scheduled for this Friday; we're hoping that we can submit this CN for TC review;. Then we hope to offer this to public for their feedback, but first it has to be reviewed by TC.
Kris; What I suggested to SC in my note was to get the CN out to the TC for review. We can have a 2-stage process;
1) TC looks at the doc and sees if we think it's ready to move forward (equiv to a stage 2 proposal).
2) If so, then we need to review it in a diff way; do we want to approve it as a CN to go out to the public? If we want public review, we should seek public comment back on it in OASIS 30-day review.
[resolution; Carlos will send out latest draft for review]
6. Subcommittee governance
Current document: https://lists.oasis-open.org/archives/dita/201705/msg00051.html
https://lists.oasis-open.org/archives/dita/201705/msg00055.html (Chet Ensign, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00056.html (Eberlein, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00057.html (Chet Ensign, 24 May 2017)
https://lists.oasis-open.org/archives/dita/201705/msg00076.html (Chet Ensign, 25 May 2017)
Kris; Chet's last suggestion seems reasonable, I think.
Nancy; what does that mean about who will 'own additional content outside of OASIS'?
Robert; I think he's willing to talk about that.
Kris; I don't think we have to talk about IPR restrictions until we're actually in the situation, just as, when we put something in a OASIS Github repo, there's licensing associated with it. Let's hold this till Bob is on the call, since he authored the SC goverance doc.
7. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
Style sheets: Progress?
[Bob not here]
New item: Wrong default version number in RNG
https://lists.oasis-open.org/archives/dita/201705/msg00080.html (Anderson, 26 May 2017)
Robert; this only happens in one of the modules, but it needs to be fixed, pretty trivial fix.
Kris; any objections to making the fix for Errata 02.
[none]
ActionItem: Robert will make the fix and note it in errata doc
8. Review of stage one (in progress) cards
Project page at the GitHub repo: https://github.com/oasis-tcs/dita/projects/2
a) Deprecate or remove copy-to attribute
Chris; I think that was mine. The copy-to @ assumes cetain things about the way processing is done, specifically the dita-ot way, and with key-scopes that's the wrong way. We should find some other way to address those needs and remove copy-to.
Eliot; keys already provide a way to do that, i.e., provide a unigue ID for that ref for that topic in that map; sufficient to generate unique output.
Kris; just playing devil's advocate here, but I know we have a number of vendor solutions that don't support keys very well; what happens if we remove copy-to
Chris; nothing worse than what will happen when we shore up our conformance statement
Eliot; if you're not supporting keys and using copy-to, probably doing it wrong anyway.
Robert; with keys becoming more and more central, apps that can't handle keys will have a hard time claiming conformance with 2.0.
Kris; that said, what do we want to do? deprecate or remove?
Robert; support removing
Eliot; ditto
Nancy; does it need to be deprecated first?
Robert; no
Chris; does it need to go through proposal process
Kris; yes, we have to do that, including piece explaining rationale and impacts
Kris; to move forward to stage 2, need an owner. Anyone who can step up to this
Eliot; I can take it
Kris; I move we mone this to stage 2 with eliot as owner
Chris; second
Kris; objections?
[none, this is moved to stage 2 with Eliot as owner]
b) Change the name of the locktitle attribute to something less ambiguous, and change default to "yes" (Kimber)
Eliot; it doesn't make any sense, and no one gets it on theirfirst try; the function is useful, but the @ needs to be named in a better and clearer way.
Kris; if we change it, how big an impact will it have?
Robert; it will impact anyone who uses it.
Kris; will we wreak havoc by changing it, or will the benefits be worth the cost?
Eliot; if we change @ name and values, we might be able to come up with a name that makes the current @ values make sense.
Robert; it makes no sense, expecially when navtitle @ moved to an element.
Also, it engenders confusion
Chris; I also have a proposal for putting title-alts in various places, this will have overlap with that proposal.
Robert; it should have overlap with that proposal.
Kris; what shal we do about this? eliot; do you want to wn this
Robert; I think that it would be best to hold off till Chris comes up with his title-alts proposal, without including this as part of that.
Chris; I'll add this to my list, and will consult with Eliot.
Eliot; fixding tis will entail more complexity than just moving or renaming an attribute.
Kris; shall we open an issue for this? we'll park it until we have Chris's title-allts proposal
Robert; I'll make a note in Github, about title-alts -> locktitle, include a note in card, so it doesn't come up here again
c) Remove topicsetref element (Anderson)
Robert; this came up with people confused about topicsetref/topicset. These elements came out of a theory that it's important to be able to specify a group of topics that sould travel together. There are now other, better ways to do this, e.g. a map and mapref. This element is basically a mapref that expects to point to a map. it got some internal IBM usage. I don't think it has wide enough utility to be in the standard.
Nancy; should we remove topicset as well, or not?
Robert; do people think it's useful?
Kris; last time we talked, Robert, you did...
Robert; I think it has a clear semantic meaning; that isn't the same thing as thinking it has a real use, so I don't care if it stays or goes. OTOH, topicsetref has caused confusion.
Deb; we use topicset to apply a collection-type and ues it
Robert; you could use topicgroup for that...
Kris; why use topicset instead of topicgroup?
Deb; the collection-type @ isn't available on topicgroup, or it's not called out the same way, so we felt we needed it.
Robert; yes it is available, topicgroup just gets rid of a couple of @s, but not that. I don't really care about topicset, it could stay in.
Eliot; I'd be inclined to get rid of topicset as well, without topicsetref, why is it there?
Robert; if I needed that function, I'd create a submap
Eliot; topicset and topicsetref add a lot of complexity to map processing with no added value.
Chris; I agree.
Robert; for me, they've provided no add'l complexity, since we don't do much with them.
Eliot it appears to require you to compose a result map that includes topicset refs.
Robert; are you confusing this with navref?
Eliot; oh yeah, well, it adds nothing to maps, now that we have cross-deliverable refs,
Robert; processing is no diff from a topicset that refers to a branch of a map rather than a full map.
Eliot; but what does it meant to have a mapref ref to a topicref. what does the result look like?
Robert; almost same as a conref.
Chris; not quite the same as a conref, but almost
Eliot; s subtle difference...
Robert; it should be treated as a mapref;
Chris; I would argue that on grounds of complexity, both should be gone, people think they're special/diff from mapref, but they're not.
Kris; what do we want to do?
Nancy; I'd support tremoving them both; we're talking about 2.0 de-complexifying
DITA.
Kris; is there someone who could own this propsal for stage 2.
Eliot; I could do that.
Kris; if you take this you're maxed out at your 3.
Kris; so we'll move this to stage 2 with Eliot as owner.
[seconded by Nancy, approved by TC]
d) Deprecate type="fastpath" attribute value for note elements (Magliery)
Tom; we could generalize this idea to doing an overhaul of values defined for @type on note; I think there are a lot that are not used much
Kris; Robert, I know one thing you've been thinking of is improving coverage of @s to not be used so many different ways in different elements.
Robert; @type is the most overloaded, and the place it's most commonly used is note.
Tom; what's the implication of that?
Robert; I don't know; if we were going to change @type to be different on different elements, I'd be inclined to leave it be in note; that's where it's used the most.
Tom; how many uses of @type have pre-defined values?
Robert; not many, I think only note, though I'm not certain.
Eliot; changing @type on note would be the most logical, but also the most impactful, since it's most used there.
Robert; and some people use it as a way to class things instead of outputclass.
Tom; should we get rid of pre-defined values?
Robert; it would lead to a lot of typos... especially for machinery...
Eliot; now we have subjectscheme to define enumerated value lists.
Robert; it can be used for that, but generally won't be.
Eliot; we could provide a demo set of definitions.
Chris; I'm trying to imagine a value list extensible in place, so I could add my own.
Tom; some tools let you do that, e.g.XMetal, but that makes it invalid for the dtd.
Kris; how much utility would we get, vs. how much destruction? It's heavily used across user base; my sense is that unless there's a really big benefit, it's too much disruption
Chris; if there's a way to change it without breaking things...
Robert; the current proposal is just about fastpath, not all the note @type values.
Kris; i've never seen 'fastpath' used. I can see an argument for removing things.
Robert; it would affect my test cases, but that's all.
Tom; I don't mind owning a small item, but we should review other note types to see if there are any others that can be removed.
Kris; let's pick up in 2 weeks with looking at this.
e) Remove the locktitle attribute from topichead and topicgroup (Anderson)
f) FROM BACKLOG: Allow domains to add elements to a specific context, rather than globally. Can this easily be done in RNG? Should be part of broad DTD / RNG / XSD changes?
-------------------------
Note: LwD meeting Friday at 11AM EDT on LwD Michael's IBM number.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]