dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 25 October 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Wed, 26 Oct 2022 19:00:16 +0000 (UTC)
Submitter's message
ActionItems:
1. Robert and Kris will move @scope and @headers (on simpletable and it's specializations) into an @ group which will be specific to tech-content.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 25 October 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
===========
Robert Anderson, Bill Burns, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Eric Sirois, Frank Wegmann, Jim Tivy, Todd Thorne, Kendall Shaw
Business
========
1. Roll call
Regrets: Dawn Stevens
2. Approve minutes from previous business meeting:
18 October 2022
https://lists.oasis-open.org/archives/dita/202210/msg00041.html (Harrison, 19 October 2022)
Kris moved, 2nd Scott, approved by TC
3. Announcements: none
4. Action items
[updates only; see agenda for complete list]
11 October 2022:
Stan: Check Google styleguides (and any about standardized English) for recommendations about usage of the term "users"
- Stan; I looked up usage of 'users.' In 'standardized English, they talk about 'users', but not in a useful way for us. Wrt within Google, there was a debate ~5 yrs ago, and they moved from using the word 'user'; for the most part, they went to using mostly second person 'you', or else they use a specific role like admin. But they use 'user' a lot as an adjective rather than a noun.
5. Volunteer tasks
Keith Schengili-Roberts: Two new example topics from accessibility review
Dawn and Comtech: Develop draft of changes from DITA 1.3 to DITA 2.0 (due 25 October 2022)
[hold for next week]
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
Combined stage two and three
(Kimber) Change @poster to (https://github.com/oasis-tcs/dita/issues/753)
- Eliot; the draft got reviews, there was just one little change, so we can vote next week.
Stage three
(Anderson) New impose-role attribute (https://github.com/oasis-tcs/dita/issues/670)
- Robert; I'm very close to done; will push my deadline to this Friday.
(Kimber) Clean-up changes (https://github.com/oasis-tcs/dita/issues/397)
17 October 2022: Initial TC discussion
25 Oct. Vote by TC [see below]
7. DITA 2.0 stage two/three combined proposals
Vote
Cleanup items
https://lists.oasis-open.org/archives/dita/202210/msg00023.html (Kimber, 17 October 2022)
Eliot moved, 2nd by Bill
Voting results:
yes votes: 10 (Robert Anderson, Bill Burns, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Eric Sirois, Frank Wegmann)
no votes 0
8. Technical content review A: Task overview and elements (18 October - 01 November 2022)
Opening of review
https://lists.oasis-open.org/archives/dita/202210/msg00032.html
Updated content for choice table elements
https://lists.oasis-open.org/archives/dita/202210/msg00042.html (Eberlein, 20 October 2022)
https://lists.oasis-open.org/archives/dita/202210/msg00045.html (Harrison, 24 October 2022)
Interim status
https://lists.oasis-open.org/archives/dita/202210/msg00046.html (Eberlein, 25 October 2022)
- Nancy; I had a question about choption @headers; I didn't understand the description, so went to the example, but there was no instance of that.
- Kris; I'll defer to Robert.......
- Robert; I'm not sure how it would be used by authors or implementers; for accessibility, the tools have accessibility tagging that would do it for you; if not, an IA could use it and hope your processing tool will use it. But it's an extreme edge case. If you're required to add this, your tools are broken.
- Gershon; why not delete it?
- Robert; because there are broken tools in the world. it's easier to keep these, and keep them in sync, than to delete.
- Kris; one possibility is to put these @s in a separate @ group
- Robert; a good idea
- Kris; would that be ok?
- Nancy; if the main description for that @ group mentioned it's used for edge cases.
- Robert; used for edge cases where you have something weird.
- Eliot; it's not that that @ is only used by processors; it's only set by processors.
- Nancy; xtrc and xtrf used to have that kind of description.
***ActionItem: Robert and Kris will move those into an @ group which will be specific to tech-content
- Kris; I've worked on Dawn's comments, except for new examples; she will develop those. Hope you'll see that most of these topics have been updated to be regular structure. Also gave illustrations of the examples, expecially for stepsection, many people think stepsection would do things it doesn't. Who else will review this?
[Bill, Stan, Scott, Frank, Nancy]
- Kris; not a lot of this content has been touched since 1.1, except to soften some normative language [e.g., 'this WILL be...]
9. DITA 2.0 spec review: Appendixes (28 September - 10 October 2022
Opening of review
https://lists.oasis-open.org/archives/dita/202209/msg00042.html (Eberlein, 28 September 2022)
Topics that need review
https://lists.oasis-open.org/archives/dita/202210/msg00003.html (04 October 2022)
Status:
Comments about "Element-by element recommendations"
https://lists.oasis-open.org/archives/dita/202210/msg00014.html (Eberlein, 11 October 2022)
Final status:
https://lists.oasis-open.org/archives/dita/202210/msg00021.html (Eberlein, 17 October 2022)
[following is discussion of comments/questions about element-by-element recommendations for translators.]
1. Why do we have a specialization base column? Is it needed?
- Gershon; think this came from a TC member, not sure reason.
- Robert; I think the column that follows are largely comments about whether they inherit translation settings from base.
- Kris; we still have the spec base column, and 'same behavior as base/ solumn.
- Robert; wrt whether we need this; it was there for base elements, and done just for consistency, I think that's now nonsensical.
- Kris; I've already removed it in drafts; only in table for domain elements column.
- Robert; I think we've updated tables so it's only there where it's useful.
2. Block/inline (presentation) column: Why do we have this? What is its purpose? What values should be permitted? Eliot suggests block|inline|metadata|subflow.
- Gershon; this came from translation SC, I think, though I'm questioning why we need this. People can use some elements in either block or inline. From translation POV, main concern wrt block vs inline is that inline elements that are not necessarily segments; they tend to be very problematic; e.g. keyword . In some languages, you don't tranlate a keyword in same way in all cases; depends on the part of speech it takes. This column is an attempt to deal with that; used to configure translation mgmt system, where you might need human intervention depending on target language. 'what's intent of this element' in translation process.
- Robert; there's columns for block/inline for both translation and presentation, and they usually match. My preference would be that we only have translation column; if there's something exceptional, then we put it in a final 'notes' column. e.g. excessive use of footnotes is hard to translate, so we should pull that info into the table.
- Kris; that's what we have in source now; I got rid of the footnotes.
- Gershon; I agree with that.
3. Values for ?Translatable content?? column ? Eliot suggests adding container.
- Kris; previously we had just block and inline; Eliot suggested adding metadata and child elements, but I think adding containers could open up a can of worms.
- Robert; my concern was it would open up confusion; a ph is inline, but it could also be a container; Marking something as a container is ambiguous, it could be a phrase or a segment. For translation tools, if something is setting off a block, the tool can mark it as a segment. Section allows plain text; a definition list in a paragraph could be a container; for most part, containers identify a block.
- Gershon; I can't think of a container that's an inline.
- Zoe; menucascade is a container that's inline.
- Robert; so if you have a container in middle of running text that has nothing but phrases, you need to know it's a block.
- Gershon; translation tools ignore containers, b/c they don't contain translatable content. It would simplify the table if we omit containers.
- Kris; I think we just want to stay with block and inline, and skip otherse.
- Robert; but people will ask why they're not there.
- Eliot; each table just needs to be complete for the included elements. So then you know you can ignore that issue for the tables that don't have that column.
- Gershon; when we did it, that's why we did it. maybe we should say before table that containers that don't contain translatable text aren't in the table.
- Kris; I'd worry about doing that. I think we should get feedback from Andres and Rudolfo.
- Robert; and we should create that list, of all containers, block and inline, before we say they should be stripped.
- Gershon; or else put something in to indicate the column is N/A for that table.
- Kris; right now, we directly say whether they can or cannot contain translatable text.
- Gershon; when we came up with this table, translation tools were in their infancy.
- Robert; and I have encounter confusion from people wondering why we have translate @s on elements that don't contain text. And some people understand 'don't have text' to mean 'is empty' rather that it's actual meaning of 'doesn't have PCDATA in content model.'
4. List the few attributes that might need translation in a separate section
- Gershon; this doesn't need discussion.
- Kris; right, there are so few that they're called out separately.
5. Block/inline (translation) column ? -- What does it mean for an element to be a block? Can an image be a block or is it just a container (as Eliot suggests)?
- Kris; we've hashed this out.
- Gershon; from an translation perspective, it's not a DITA issue.
- Kris; basically, if there's an alt child, than image is translatable, otherwise not.
- Gershon; but alt will come up anyway in translation process, not as part of image; there's nothing in an image itself that needs translation.
10. Migrating to DITA 2.0 committee note
Working draft 01
Suggestion by Eberlein
https://lists.oasis-open.org/archives/dita/202210/msg00039.html (Eberlein, 18 October 2022)
- Kris; sent email with my thoughts on what would be helpful (see email). Right now there's a high-level section on what's been added, etc. But a table would be useful, as well as a list of elements that have a new specialization base in DITA 2.0, which folks could reference when considering whether they need to update specializations or stylesheets.
- Eliot; it's still very basic, not really ready for editorial review.
- Kris; but I'm wondering if you have any things you want folks to take a look at.
- Eliot; started just going thru Zoe's outline, but got distracted by cleanup proposal, then I had to change stuff, so had to come bak to draft.
- -Kris; just let us know whe you want feedback.
11. DITAVAL file syntax
https://lists.oasis-open.org/archives/dita/202210/msg00043.html (Jim Tivy, 23 October 2022)
- Jim; had to hunt around, had to reverse engineer, put together a BNF structure of DITAVAL files, so that's what motivated email
- Robert; so is the DTD and RNG not enough?
- Jim; it's not abstract, and RNG is too hung up on syntax, BNF is more readable.
- Kris; if your looking in repository, drill down into doctypes in base, there's a ditaval folder. That should give you a lot of what you're looking for.
- Jim; if there's a good RNG, that's a help, but for user, not so useful.
12:02 pm ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]