[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Minutes from June 1, 2021
Here is the attendance for 01 June 2021:
Unfortunately I missed the attendance because I was arguing with finding my oasis login. However, the rest of the minutes: 01 June 2021 11 AM ET open 1. Roll call - [Missed] Regrets: Nancy Harrison, Deb Bissantz, Frank Wegmann, 2. Approve minutes from previous business meeting: 18 May 2021 2021 https://lists.oasis-open.org/archives/dita/202105/msg00029.html (Harrison, 20 May 2021) Kris: Moves to approve. Eric S. : Seconds KE: Any objections?...Hearing none, minutes are approved as submitted. 3. Announcements -None- 4. Action items Kris did some, will continue to work on them. 5. Check-in: No business discussed. 6. Review of DITA 2.0 proposal deadlines https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 Kris Eberlein: Only one proposal. Kris has recieved feedback from the reviewers. Intends to turn around this week. Should be on agenda for the 8th for initial TC discussion Any Q? 7. NEW Need to appoint or reappoint the DITA TC chair https://lists.oasis-open.org/archives/dita/202106/msg00003.html (Eberlein, 01 May 2021) Kris: Reminder, need to do this every 2 years. Kris is willing to continue, but anyone else can propose themselves or others. 8. DITA 2.0 stage three proposals None 9. NEW DITA 2.0 troubleshooting: diagnostics_general OR diagnostics_steps (not both)? https://lists.oasis-open.org/archives/dita/202105/msg00030.html (Stevens, 20 May 2021) Dawn Stevens: Silke was the main proponent for the Diagnostics proposal. It would be non-step (e.g. table, how to figure out) or step...but not both. However, Silke has identified a scenario where both are necessary, a flowchart followed by procedures. As written, the diagnostics proposal doesn't support that. Dawn would like to switch it to just "you can have both instead of just either or", but sending to the list for other proposals. Kris Eberlein: would like to see an actual example. Are the 'steps' actual steps, or identifying call outs in the flowchart? (has contacted Silke) Have you seen an actual example? Dawn: Not yet. Will follow up. Kris: Eliot, you chimed in in the past, anythign to add now? ... Dawn, going back to you...both will work, but it will make harder for style sheets. Makes it difficult to figure out how to title things. I'd really like a use case, but will defer to others. Thoughts? Eliot: What is the form of the flowchart? Is it just an image? What is the relationship between flowchart and steps? Dawn: interpreted it that the flowchart was high level view, with more details in the steps. (Which is why Kris wonders if it's just callouts) Eliot: It would be natural for diagnostic steps to have some sort of intro, but not sure it solves everything. Kris: That would be my feeling as well. Can we jigger diagnostics_steps to have something that could contain an image. Dawn: Could do something like <stepsection> to insert an image at the beginning? Eliot: Seems reasonable. Kris: Kinda what I was thinking of. But lets get some examples to find an appropriate solution without guessing. Dawn: Will reach back out. Kris: Robert, given content model of stepsection, will this work. RObert Anderson: Matches list item, so should work. There might be something wierd if you do this without adding a following step. Exact definition of stepsection is not quite right Kris: we could change the definition of stepsection Eliot: Are there other use cases? Robert: Usually put into <context> Eliot: So this is a related image? Robert: Related to steps vs steps-informal. Hard to know what's appropriate without a solid example. Dawn: Yup, will follow up. Kris: and we'll do our best to rejigger diagnostics_steps or whatever is appropriate. 10. NEW Inconsistency in markup + xml mention domains https://lists.oasis-open.org/archives/dita/202105/msg00032.html (Anderson, 21 May 2021) Robert: [Content of email as that was the faster way to get the summary: Editing spec involves a lot of tedious work, but I'm finding stuff. I've been making my way through the tech-comm updates making updates for DITA 2.0, and noticed an inconsistency in the DITA 1.3 spec. The <markupname> element (specialized from phrase) and the XML mention elements (7 elements specialized from <markupname>) all state that they use the universal attributes + outputclass + keyref: However, in the DITA 1.3 vocabulary files, they don't define keyref: We need to fix this for DITA 2.0. Either of these options is valid for the new release; should we: - Add keyref to these elements (update 2.0 to match the 1.3 specification prose), or - Remove keyref from the spec (update 2.0 to match the 1.3 grammar files)] Eliot: apologies for making the mistake, but vote for adding keyref. Robert: me too. Was surpirsed it wasn't there. Scott Hudson: Yes, add keyref. Kris: use case? Robert: Can link to something. Kris: That's a use case. Any objections?....Add to fix list. Robert: Spec was right, so we just need to fix it. 11. NEW Follow-up on longquoteref https://lists.oasis-open.org/archives/dita/202105/msg00033.html (Anderson, 21 May 2021) Robert: [Content of email as that was the faster way to get the summary: As noted at the TC week, our overlapping capabilities with <lq> and <longquoteref> are more complicated than I thought. The current status is: * The <lq> element has linking attributes (href, scope, format, type), although type has an alternate definition, which no longer really makes sense. It also has the reftitle attribute to specify the title of the source of the quote. * The <longquoteref> element lets you specify a link within the content, but is empty; it cannot specify the title. If associated with a key, then it could be associated with a title, but the grammar does not let you specify one. * <lq> also allows <xref>, so with child elements it can specify normal links + a link to the source (minus title). That seems odd / inconsistent / excessive, with two ways to express the same source information and only an attribute to specify a title. It came about in DITA 1.2 when the long description links on <image> were moved to a sub-element, with the same operation done here. Image doesn't have a title, which is probably how we ended up not including the title here. It's really not clear how best to clean this up. I see a few options: 1. Ignore it and we have this confusing overlap. 2. Allow text / phrases in the longquote ref, so that it can specify a title, and remove the linking / reftitle attributes from <lq>. It's still a bit odd that we can specify both <xref> and <longquoteref>, but it has a clear purpose and we only have one way to indicate the source of the quote. 3. Remove the attributes and the longquoteref. If you want to specify the source of the quote, you have to use <xref>. If you want special styling, you probably use @outputclass and customize styling. 4. Remove the linking attributes and the element, but add @keyref to <lq>. This makes the block long quote sort of like keyword, phrase, and other non-linking elements that can link if you set up a key. This would also be a way to specify a title (use keyref, with or without a link). My personal preference is for option four. It simplifies the language by removing an element and several attributes, but makes use of common keyref behavior to provide the same overall function (connecting the quote to the source of the quote and/or title of the quoted document). But I've also seen very little use of this element, so if anyone thinks it is used more widely, it might be better to go with one of the other options.] Pretty sure this is rarely used, since no one has complained. I've only used it in test cases. What do folk think? Scott Hudson: I also favor option 4. Eliot: See the attraction of 4, but prefer option 2. It preserves an element people might be using. Looked up <blockquote> in HTML5, there is one attribute, @cite. Should we make parallel with HTML5? Robert: THere is certainly overlap with site as well. Eliot: But I'll accept option 4. Robert: and <cite> doesn't have a linking attributes, but it does have @keyref. Eliot: I'd be fine moving it to <cite> Robert: Update option 3 to use <cite> instead of <xref>. Preferred option 4 because it's so close to <xref> or <cite> Eliot: Could link to quote, or the quote in source, or the souce information. Robert: Not precluding the use of <cite> for references. Kris: Like the new direction from Eliot. I was concerned about option 4, you'd have a quote 3-4 paragraphs long, and then you'd have them all be hyperlinked as a quote, which while valid, would look ugly. Most likely not what people want or expect. Robert: Well, @href has been available in <lq> since 1.0, but most people have dealt with that. <I got lost here> Robert: When you resolve @keyref, you can get the reference. Kris: Any other comments? Robert, Eliot, where do you think you were going with <cite> Eliot: Resolved option 4 + existing ability to use <cite> gives everything I want. Robert: Yup. Kris: Does the content model for <lq> permit <cite> Zoe: Make sure there's something for the migration guide. Robert: Yes, will be added to GitHub issue (397). Kris: Any objections?...Done. Robert, please add to the issue. 12. NEW LwDITA markup inconsistency, missing keyref on highlight elements https://lists.oasis-open.org/archives/dita/202105/msg00039.html (Anderson, 24 May 2021) Robert: Missing @keyref on some of the highlight elements. Possibly was to move people towards using semantic element, by making them not quite as useful. However, now with LwDITA, that doesn't make as much sense. [Content of email as that was the faster way to get the summary: Perhaps I should stop digging through DTDs and RNGs, but while doing so I've found another inconsistency. This one is actually an issue for LwDITA rather than for the base spec, but addressing it likely impacts the base spec. In LwDITA, all phrase-level reuse is done with the keyref attribute, rather than conref, as part of an effort to make sure there is only one way to reuse any type of phrase. This means that the LwDITA modules expect keyref to be on highlight elements such as <b>, <i>, and <u>, as well as the upcoming elements <em> and <strong>. The %variable-content; entity in here adds keyref to five highlight elements: https://github.com/oasis-tcs/dita-lwdita/blob/master/org.oasis-open.xdita/dtd/lw-highlightDomain.mod#L45 The problem is that in the base DITA vocabulary, none of these elements allow keyref, so specifying it on LwDITA highlight phrases means that those elements are no longer a valid subset of DITA. It's not there in DITA 1.3 grammar and it's still not there in the DITA 2.0 definition. Digging deep into memory, the only reason I can think of that it was left off was to nudge authors into using more semantic elements for reuse. These elements all specialize from <ph> which does allow key references, so it would be legal to add it. Given the LwDITA use case, it seems like at this point we should probably let these elements use keyref, unless there is a compelling reason to keep it off. If we do decide to keep it off, that means a fair bit of churn in how reuse is managed in the context of LwDITA.] Robert: We should just @keyref so they are consistent and avoid reworking the reuse model of LwDITA. Carlos: Thank you. We have a lot of early adopters using this, so very much appreciate the consideration so LwDITA continues working. Kris: Any objections?...Another cleanup item. Robert: I should stop finding these. Kris: No please, keep finding them. 13. & 14. XDITA grammar files compatible with DITA 2.0 https://lists.oasis-open.org/archives/dita/202105/msg00019.html (Evia, 13 May 2021) Kris: Carlos asked for help moving the LwDITA DTDs forward to DITA 2.0. I have done this work. However, there are questions. Please bring them back to the sub-committee. <strong> and <em>, separate domain? or part of highlightDomain. Carlos: Thank you. I've added <strong> and <em> to the highlightDomain. Trying to have the grammar files as complete as possible, but need to remember/ask why. Kris: Rather odd. Original reason for separating out highlightDomain was to constrain or remove for implementations that didn't want them. If there are implementation that want to get rid of the overlap, having them separated might make that easier. Carlos: Would like <strong> and <em> as baked into base.mod. Wanted something quick and dirty for folks to play with. Kris: Was keeping them separate for easier removal for folks using more semantics. Remember, DITA2.0 has highlightDomain and strong/em domain. Robert: I can't remember why it was a separate domain. Will LwDITA folks customize anything? Eric Sirois: Can we say the same about multi media? Kris: Multimedia elements are now part of base. Robert: Really not sure how many people using LwDITA are going to go in and make constraints. This is a choice for the LwDITA committee. Gershon: Most DITA users don't specialize [easily constrain]. I would extrapolate LwDITA is going to be used out of the box. If the sub-committee doesn't care, we shouldn't worry about it. Assume that most folks will be using it as is. Carlos: I'll brign that to the LwDITA sub-committee. 1. Keep in base.mod 2. Keep in xdita highlight domain 3. Make a new domain. Robert: Not sure 2 makes sense, since it's contradictary to the main DITA domain. Most likely, people will want to remove one set, so keeping separate makes it easier. The solutions should be 1. Keep in one domain. 2. Separate into 2 domains Kris: Since I've been in LwDITA topic and LwDITA map. There are elements redefined in both of those, e.g. <image> and <xref>. If we put all elements in to .mod, is it worth having a .mod that has common elements between topic and map. Carlos: To be honest, not sure anyone has touched the map.mod for ~3 years. Will bring this to sub-committee. The common elements .mod makes sense. Kris: I did extra work to make sure like elements were defined the same, and it was a pain. Also, do you need/want the <fallback> element? It's part of the formal definition for <audio> and <video> in DITA2.0, but not part of LwDITA. Carlos: That's because HTML5 doesn't have an easy way to map. I can bring it back. Kris: if already decided by the sub-committee, let's considered it done. Robert: what is the HTML5 fallback method? Carlos: There isn't one. Chris Nitchie: actually, whatever is inside the element becomes the fallback. <RA and CN discussed HTML5 details and I got a little lost> Robert: Seems odd to specify Fallback. Long term would be a failure. Should be re-addressed. Carlos: Will bring back to the sub-committee. End meeting. Don't forget reviewing the webinar slide deck or the charter work! 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) Ongoing Work on TC charter https://lists.oasis-open.org/archives/dita/202105/msg00022.html (Wegmann, 18 May 2021) https://lists.oasis-open.org/archives/dita/202105/msg00025.html (Harrison, 18 May 2021)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]