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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Minutes 8 June 2021


I was not able to keep up typing with the list of vendors Kris was reading off, so I'm hoping to get that, but I didn't want to delay the minutes any longer.

Remember to register for the webinar. We won't be using the regular dial in next week.

ZoÃ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
08 June 2021

11 AM ET open

Roll call
Voting Members: Zoà Lawson, Kris Eberlein, Eliot Kimber, Chris Nitchie, Keith Schengili-Roberts, Eric Sirois, Robert Anderson, Gershon Joseph, Scott Hudson, Frank Wegmann, Carlos Evia
Non-Voting: Jim Tivy

Regrets: Dawn Stevens, Nancy Harrison, Carsten Brennecke, Deb Bissantz

Approve minutes from previous business meeting:

01 June 2021
https://lists.oasis-open.org/archives/dita/202106/msg00010.html (Lawson + Eberlein, 08 June 2021)
	Eric Sirois Seconds
	Any objections? 
	Hearing no objections, minutes are accepted as submitted.

Announcements

Nancy Harrison has a broken wrist and needs to take 6-8 weeks off from taking minutes. Deb Bissantz has volunteered to replace her.

	Kris: Big thanks to Deb

	Reminder: Next week isn't a DITA TC meeting, but vendor webinar.
	Please register for that. [Link here: https://zoom.us/webinar/register/WN_TI4raho9TXazDvJSuBtSzw]
	Kris will repost that link to the list so we can register.

4. Action items

	[NEW] Kris - please add the link to Vendor webinar: https://zoom.us/webinar/register/WN_TI4raho9TXazDvJSuBtSzw
	[NEW] Everyone: Register for it.
	[NEW] Kris - Draft wording for the @specification changes and send to Robert Anderson and Eliot Kimber for review via the list
	Kris: reviewed list from Kieth. Only on Japanese vendor not already  on the list. Will follow up.


5. Check-in: How are people doing in this difficult time? How is your state/country doing?
	No business

6. Review of DITA 2.0 proposal deadlines

https://wiki.oasis-open.org/dita/DeadlinesDITA2.0

	Kris: Hoped for initial discussion for final stage 3 of loosening attribute specializations. However, life happened. Am working on it, expect to have the work done this week. Possibly more questions.
	There's a question on the agenda for today. This proposal touches so much of the spec, hard to contain well.

7. Reappoint Eberlein as the DITA TC chair

https://lists.oasis-open.org/archives/dita/202106/msg00003.html (Eberlein, 01 May 2021)

	Kris: willing to do.
	Eliot Kimber: Moves that Kris Eberlein is reinstated as the TC Chair for 2 more years. 
	Carlos E: Seconds
	Kris: Any objections?
	
	No objections (even though Kris asked for them :-) ) 

8. Report from LwDITA subcommittee (Evia)
	Kris: Where is the sub-commitee at?
	Carlos: Have been working on spec. Ironing out things in MDITA based on IBM's implementation (Jennifer Schlotfelt), because they don't want to break working implementation.
	Have switched gears to XDITA implementation grammar files. Focused on the grammar files to make them releaseable at the same time as the DITA 2.0 
	Unfortunately, probaly not going ot make that date.
	Conversation about fallback. Fallback was supposed to be in HTML model for XDITA, not sure why it disappeared. Probbaly because HTML5 doesn't have an element for it, because as Chris Nitchie and Robert Anderson pointed out, anything in the element works. Working on implementing it.
	Michael pointed out that LwDITA wants 2 domains for emphasis and highlighting. Domain is emphasis and highlighting
	Keith Schengili-Roberts - that's what I remember
	Robert Anderson: Yes
	Carlos: That's what I've done. No longer in topic.mod, refers to the domains. Michael may be correct that some people want to rename <em> and <strong>. So working on the separation of the demails.
	Delayed conversations due to missing folks:
		- To have a separate file that are shared between topic and map. On agenda for next meeting
		- Frank mention in conversation with ??? for a JSON flavored LwDITA. If it happens, not going to happen in 1.0 LwDITA. 
	Frank and Carlos are having spec editing meetings on Mondays. Planning on moving forward. Not accepting more changes, working on implementing what's been decisded and aligning with DITA 2.0.
	Questions, comments?
	
	Kris: As we've made some changes to 2.0, may need to re-examine common content, reuse, etc. Also, Robert's work on Attributes will probably also need to be reviewed.
	
	Carlos: Yes, aware, and a focus for Mondays. Will reach out if we (Frank and Carlos) need help.
	
	Kris: Robert, any comments?
	
	Robert: Not really. Just making sure things are still accurate. Look for Draft-comments that should mark where he was concerned.
	
	Kris: Concerned that we don't have the same attribute groups. Especially how constructed with Entites in DTD files.
	
	Robert Anderson: That shouldn't impact the spec. The work we've done with attribute groups is to remove extra confusing stuff. LwDITA was already removing those things, so it should be okay. Linking targets might impact, but 
	
	Kris: Carlos and Frank, please keep us in the loop. Let us know if you need to set up extra meetings about shared stuff.
	
	Carlos: Attributes are hard. E.g. XDITA. You bet we'll be in touch.
	
	Kris: Any other
	
	Eric Sirois: Not sure if looking at latest version, but media related elements have a specialized format for @class and different than 2.0. Planning to roll in 2.0 work?
	
	Carlos: Yes, Kris is doing that work.
	
	Kris: Make sure you're looking at the DTDs from the LwDITA GitRepo. Don't look at DITA-OT or OASIS, those are back-level.
	
	Carlos: Looking to release to GitHub after next meeting when can make changes based on decisions.
	
	ES: so, where is the repo? 
	
	Carlos: Are you going to the spec branch?
	
	ES: No?
	
	[Discussion of how to find stuff in GitHub]
	
	Kris: There are two LwDITA github repos. There was an open one and then an official OASIS one that started later. Use the Official OASIS github AND make sure you're on the spec branch.
	If anyone has idea about how better to point folks in the right directions, please discuss on the list.
	Also, scroll down on the front page of the wiki and find all the official links to the GitHub Repos.
	May need to add details about branches.
	
	[From front of wiki:
		OASIS GitHub repositories:
			Spec: https://github.com/oasis-tcs/dita
			Committee notes: https://github.com/oasis-tcs/dita-committee-notes
			DITA for Learning & Training: https://github.com/oasis-tcs/dita-learning-training
			DITA for Technical Content: https://github.com/oasis-tcs/dita-techcomm
			LwDITA: https://github.com/oasis-tcs/dita-lwdita
		Open OASIS GitHub repositories:
			RNG-to-DTD converter: https://github.com/oasis-open/dita-rng-converter
			Style sheets: https://github.com/oasis-open/dita-stylesheets]

	
	
9. Normative rule about @class and @specializations required on the root element of every topic and map

https://lists.oasis-open.org/archives/dita/202106/msg00011.html (Eberlein, 08 June 2021)

	Kris: This cropped up as rework of speciallizations attributes (and more to do with droppign @domains)
	For 1.3 every root element needed @class and @specialization.
	For 2.0, does every root need to declare @specialization if there are no attribute specializations?
	Would like us to hammer out what we want to say when there are no specialization.
	
	Robert Anderson: Actually, not about what to do if there are no specializations. 
	You can only declare the specialization in the .mod or the document.
	It's not about the shell.
	
	Kris: apologies for mis-speaking
	
	Robert Anderson: no problem, this is confusing.
	For example, needs to be an exception for <dita>
	Whenever you specialize a topic or map, even if you don't ever plan on having specialized attributes, 
	Okay with SHOULD, because it's forward looking. Saying MUST means you have to define it, even if you are never going ot use it.
	
	Kris: From the point of view that has the normative rule, it largely duplicates information that's in the following statement on @Class.
	I'd like to remove this normative rule, but clarify what to say about @specialization. It should be in the @specialization topic, not the @class topic.
	
	Robert Anderson: I agree. other thoughts?
	
	Zoe: Confused about is it the statement or is it about the location of the information?
	
	Kris: Two fold, both of these questions.
	
	Robert Anderson: Right now from the spec, we say "You MUST define the @specialization"
	Do not like.
	Remove normative rule and just say what it does?
	
	Kris: And Eliot is adding some particular edge cases.
	I'm looking at current @specialization topic, and it does have a normative statement on @props and @base. Does that adequately cover?
	I want conversation so it's not my personal decision.
	
	Robert Anderson: Yup, aware, but not opinions from TC.
	
	Eliot: Reviewing what I wrote. Understand what Robert is saysing. However, It's a simple rule, which may be better if there is no bad result.
	
	Robert Anderson: There's a difference between a Normative statement vs just "here's what it does"
	
	Eliot: I will defer to Robert, don't have a strong feeling.
	If we allow @specialization to be ommitted, when there are no specializations, it makes the Normative statement more complicated, but the document is clearer.
	[Apologies got lost taking notes]
	
	Robert Anderson: In the past, we said you had to have @domains and define tokens. This assumes that you will always have a domain. However, that's not always true. e.g. there was a map specialization that had no domains. Validating editor invalidated the entire file, and it was a pain.
	
	Eliot: 
	
	Robert Anderson: Must be specified vs must be defined at root element?
	
	Eliot: The root element .... There made
	
	[Got lost in details]
	
	Kris: If we expand the @specialization topic, and it does have a normative statement on @props and @base. section to be more specific about @specialization, would that handle the situation?
	
	Robert Anderson and Eliot: It might...
	
	Kris: That would let us remove the normative statement that Robert doesn't like, and expand the other info.
	[NEW ACTION ITEM] Will write up and run by Robert Anderson and Eliot Kimber (and list).
	
	Eliot: I reread... "Declare" is the confustion. Declare has to be in the grammar, but maybe not in document?
	[spitballing words to state it]
	
	Robert Anderson: this is why I've been having difficulty.
	
	Eliot: If normative rule is defined for "instances", yeah, we shouldn't have the normative rule so editors don't validate the wrong thing. 
	Agree that Kris's statement might work.
	
	Kris: Move this discussion to email?


10. SKIP DITA 2.0 stage three proposals

11. SKIP Continuing DITA 2.0 troubleshooting: diagnostics_general OR diagnostics_steps (not both)?

On hold waiting to see example from Erikson


12. Continued: DITA 2.0 Webinar for vendors?

Starting point for Webinar slide deck?
https://lists.oasis-open.org/archives/dita/202105/msg00003.html (Eberlein, 04 May 2021)

NEW https://lists.oasis-open.org/archives/dita/202105/msg00020.html (Bissantz, 13 May 2021)


	Kris: Deb will moderate chat. Robert Anderson will be on hand for answering questions. 
	Hoping most questions would be on the 29th.
	Chris Niche, I hope you're available for questions too.
	
	Chris Nitchie: Sure.
	
	Kris: Thanks! Chris Nitchie and Robert Anderson and KE have the most proposals, so thank you.
	Who has registered:
	[KRIS, can you give me this list, I couldn't keep up]
	datazone (Miramo)
	Navastar (Heavy Equipment manufacturer, DITA Users)
	Bluestream
	DITA Strategies.
	Dakota systems
	Bill Burns simple A 
	
	Also "private" emails gmail, etc., so can't tell the company. 
	
	Kris will send an email to folks not on the list to make sure they're aware...
	
	Gershon: I did reach out, but didn't hear back.
	
	Kris: it will be recorded, we'll put it up on YouTube.
	Deb will help with slides on Wednesday. 
	Kris will reach out as necessary.
	There may be more work for the Q&A follow up.
	Comments? Questions?
	
	Thank you!


12 noon ET close


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