dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 8 March 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Mon, 14 Mar 2022 18:16:00 +0000 (UTC)
Submitter's message
ActionItems:
1. Scott will talk to Chet about coming to a session with Radu on using Oxygen tooling for spec review, and will then copy Robert and Kris on upshot
=================================================
Minutes of the OASIS DITA TC
Tuesday, 8 March 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Dawn Stevens, Frank Wegmann
Business
========
1. Roll call
Regrets: Carsten Brennecke, Eric Sirois
2. Approve minutes from previous business meeting:
01 March 2022
https://lists.oasis-open.org/archives/dita/202203/msg00004.html (Harrison, 05 March 2022)
Kris moved, 2nd Scott, approved by TC
3. Announcements
none
4. Action items
[no updates; see agenda for complete list]
5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
Stage two
(Eberlein) Remove classification domain and add new attribute (https://github.com/oasis-tcs/dita/issues/647)
(./) 07 March 2022: Submit to reviews (Brennecke, Joseph)
?: Feedback provided by reviewers
?: TC discussion
?: Vote by TC
Kris; sent out proposal #647 to TC, as well as to Joe Galbertson (sp?) plus to contacts at some education compainies who use this domain. Once we have review, hope for quick turnaround. also tried to get back to the project of updating the spec to implement loosening @ requirements.
6. Review L: DITA linking
Opening of review: https://lists.oasis-open.org/archives/dita/202203/msg00003.html (Eberlein, 03 March 2022)
What's changed since DITA 1.3
Kris; this will be a small review, just covers the 4 linking format @s; @href, @scope, @type; only Zoe has commented so far; pls review and make comments this week.
Robert; nothing to add
Kris; these were originally in the element language ref in previous versions of spec. We thought they're critical @s for linking, so moved them into the arch spec and did some editing on them.
Robert; while this info already existed in arch spec, it wasn't consistenet with what was in language ref.
Kris; btw, it includes a reference to peer maps.
7. Continued: Cascading of roles
https://lists.oasis-open.org/archives/dita/202202/msg00030.html (Eberlein, 28 February 2022)
Pick up discussion where we left off on 01 March 2022
Kris; thorny issue of cascading of roles on topicref elements, wrt role of chapter, cascades to a chapter element that refs a ditamap.
Robert; the issue is ugly stuff in 1.3 that needs cleanup. If you reference something that's a submap with a chapter, you're declaring a role for the branches - that they're chapters. Spec says this has to happen with chapters, but we don't give any way to declare. it's perfectly fine for a specialization to be declared with a specialization role, but we have no way in the language to actually say that. The suggestion is to have new @ to declare this behavior, so we can get rid of the ugly stuff in the spec.
Eliot; there are 2 diff ways we could define this, for the 2 main diff use cases. For the one Robert described. if it references a map, then implication is that branches in map are chapters. The other use case is, if there's a specialized topicref that is specifically a mapref, i.e. has @format of ditaIap, but I want that to impose a specific processing, e.g. a chapter mapref specialization where its elements still have chapter imposed on them. That makes it easier to have authors know when to reference a topicref and when to reference a submap. This could have the rule that Robert stated, so as to have a way of stating if you reference a submap, its type is imposed on the branches. otherwise, if type=x, impose topic type branches on branches of submap.
Robert; that makes me nervous; it's switching from 'does this push or not?' to determining how it pushes things; there's no other way of declaring the element.
Eliot; I don't think the second one is a use case we need to cover; simpler use case is sufficient; if I want the complex, i can define the specialization, so that submap only allows branches to be chapters, to get the semantics that I want.
Robert; anyone have thoughts?
Nancy; are there migration impacts?
Robert; none; implementations would have to treat it as a new feature. adding it because there's no way to do it today.
Scott; and we don't want to oveload cascade @.
Eliot; as far as a name for this @, I suggest @impose-semantic-role?
Robert; my original thought was @preserve-role, but not committed to that, otoh, yours is long for an @...
Eliot; the term role has so many meanings that we needed to make it clear.
Scott; what about @impose-semantic?
Robert; I also thought of @impose-map-role, but that's not specific enough.
Eliot; this @ will only ever be set in parameter entities, not by authors.
Robert; so let's go with @impose-semantic-role for now. Next is for someone, probably me, to do an actual proposall. So we'll have another proposal for 2.0.
8. Review tooling
https://lists.oasis-open.org/archives/dita/202111/msg00006.html (Eberlein, 02 November 2021)
https://lists.oasis-open.org/archives/dita/202111/msg00016.html (Hudson, forwarded by Eberlein on 09 November 2021)
Update from Scott Hudson
Robert; Scott, so you have an update?
Scott; there's a link in wiki to some correspondence with Radu from SynchroSoft (Oxygen). The sticky part is that there are things we'd need to add to our build process in our repo to generate review copiew; they can render to their webhelp version of content, so we'll have a web view of spec, and with their add-ons, it allows you to add comments to version, then adds changes to repo if you have permission. They have ContentFusion, but this doesn't have the same level of flexibility. They are willing to donate licenses to use the tooling; it really depends on whether we can set up the tooling to make those changes. Radu has an examople you can look at, but it's not in the email. Here's the link to it:
https://www.oxygenxml.com/oxygen-xml-web-author/app/oxygen.html?url="" />
Scott; so we put in our comments, and since it's connected to git, it can be included if you have right with permissions.
Robert; so they're storing it in Github?
Scott; yes
Robert; but our Github is controlled by OASIS; if it requires setting up a new fork, that won't work, because OASIS controls that very tightly.
Eliot; what if we create the fork to do that with?
Robert; but someone would have to own the fork. if they want it to be available transparently to everone. if that went into our topics.
Frank; is it possible to get the process apart from Github?
Robert; I'm conflicted; I really don't like DITAWeb, it's very cumbersome, though it would work well for simple changes.
Scott; if you're using Oxygen already those comments show in review pane, but in a text editor, it woud be a mess.
Robert; I was thinking of Github view, which is text based.
Scott; they do have a review tool; that could be separated from Git, I think Oxygen would be amenable to doing that. I'm not sure how we could host the server thru OASIS.
Robert; I don't think OASIS would want to maintain their software.
Scott; Kris worried that with an Oxygen server, how can process be really open? For reviews; people would need to register for an account to make a comment.
Robert; we would need to limit comments to TC members.
Stan; we tested using ContentFusion with a dedicated server and it worked very well.
Robert; I know that OASIS has some add'l requirements; e.g., being able to collect a PDF with all comments and having public access.
Stan; as far as being able to archive comments, there's a flag that lets you render the comments for tracking changes. so you can generate those copies.
Frank; Do we have an option to invite Radu to talk to us about the issuem, to see if we can do this within OASIS restraints and our own requirements?
Scott; depends on whether we want the Github-connected version, or standalone ContentFusion version.
Robert; I don't want to waste Radu's time, but we might need to have the session with Chet Ensign from OASIS there, so OASIS doesn't put kibosh on it.
Scott; so I'll follow up with Chet to see if he has red flags to start with.
Robert; my biggest concern is with Oxygen PIs ending up in the source; they absolutely can't be part of source.
Scott; from my testing, you assemble a review pkg with your local desktop and upload it to the server, review activities take place on server, then afterwards you pull them back to your version; we can make it as clean as we want to before we put it in our source repo.
***ActionItem Scott will talk to Chet about that and copy Robert and Kris on upshot
Other:
Robert; please everyone review the linking @s
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]