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: Groups - DITA TC Meeting Minutes 13 September 2022 uploaded


Submitter's message
ActionItems: None


=================================================
Minutes of the OASIS DITA TC
Tuesday, 13 September 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
===========
Robert Anderson, Bill Burns, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Zoe Lawson, Eric Sirois, Dawn Stevens, Frank Wegmann, Melanie Petersman, Nathanial Mohammed, Todd Thorne


Business
========

1. Roll call
Regrets: Eliot Kimber, Stan Doherty, Carsten Brennecke


2. Approve minutes from previous business meeting:
06 September 2022
https://lists.oasis-open.org/archives/dita/202209/msg00017.html (Harrison, 09 September 2022)
Kris moved, 2nd Dawn, approved by TC


3. Announcements
Agenda item #7, "Discussion of referred comments from the configuration review," will require looking at a PDF. Download review-p-comments.pdf and have it open for this item.


4. Action items
[no updates; see list of completed items in agenda]


5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
- Kris; any updates?
- Robert; I will try for end of this week, it got delayed.


6. DITA 2.0 spec review: Configuration (16-29 August 2022
Opening of review:
https://lists.oasis-open.org/archives/dita/202208/msg00032.html (Eberlein, 16 August 2022)
Interim status:
https://lists.oasis-open.org/archives/dita/202209/msg00000.html (Eberlein, 02 September 2022)
Updated status
https://lists.oasis-open.org/archives/dita/202209/msg00016.html (Eberlein, 07 September 2022)
- Kris; we have cleared all but the ones that depend on generalization.


7. (Continued) Discussion of referred comments from the configuration review
https://lists.oasis-open.org/archives/dita/202209/msg00020.html (Eberlein, 12 September 2022)
1.3.4 bullet 1
- Robert; discussion of what defines a specialized element.
- Kris; has a content model that is the same or more constrained that the one it's specialized from. This gets weird where a specialized element that contains a specializedd phrase that isn't in the original element. In this case, the specialized phrase has to have child eleemnts whose ancestors are allowed in the ancestor element.
- Nancy; I think you should add just that; to me that's the crux of the matter.
- Scott; agree with Nancy
- Robert; we need to change some of it.
- Kris; when I added content for expansion module proposal and Eliot wanted it removed, I think I removed content relating to this use case. But the wording becomes really difficult; it's a complicated concept.
- Robert; I think we have a direction, just needing more specific wording. Eliot wondered if we needed to specify the difference between expansion and specialiization, and how @s can help. Kris followed up with 'info doesn't belong here' but we need to figure out where that info goes.
2. pdf pg 19-20
- Robert; again, this gets into whether we need more info on expansion, and the difference between specialization and expansion wrt @s. The distinction is whether you created the new module or someone did it for you, as far as I can tell from Eliot's comment.
- Frank; do we need to draw the fine distinction within the text, or can we use an example?
- Robert; I don't think it belongs here, see the title of topic; for that rule, it doesn't matter if new @s are added by contraints or by a specialization. Adding it here would imply that rules behave differently.
- Kris; I don't think we should be modifying this topic as part of this comment. But we have TC members and reviewers who are struggling with the difference between configuration. specialization. and expansion.
- Nancy; so so we need a CN?
- Kris; yes, but I would need to do it and I'm maxed out.
- Robert; we've had quite a few suggestions for CNs, and most won't happen because we just don't have the people to do them.
- Frank; could we in principle agree that it would be helpful to have a CN on that topic, but that it needs to be postponed until after spec has gone into balloting phase?
- Kris; that's a good idea. One of Zoe's comments was "I don't understand the diff between specialization, generalization, constraints, and expansion, just OOTB and not. I offered to do a tutorial for her on that, and I'd be happy to have more people in that, and then maybe they could contribute to such a CN.
- Scott; great idea, maybe we could record that and use it as basis for a CN.
- Kris; that's a great idea, Scott. I've had an open contract with XMLPRess to do a book on DITA configuration and specialization.
- Nancy; I'd like to be part of that too.
- Melanie; I would be happy to attend that too.
- Kris; so what about this comment?
- Robert; deferred to a note
- Scott; agree


8. DITA 2.0 spec review: Coding practices (06-19 September 2022)
Opening of review:
https://lists.oasis-open.org/archives/dita/202209/msg00015.html (Eberlein, 06 September 2022)
Participation as of 11 September 2022
https://lists.oasis-open.org/archives/dita/202209/msg00019.html (Eberlein, 12 September 2022)
- Kris; we've had very good and solid participation so far, substantial comments, it's not a review where everyone on TC have things to offer. One of the comments from Eric about folks that tend to just add @s to specialization, which is not allowed in 1.x, but will be allowed in 2.0. This is an area where clarifying those fine points will be important
- Eric; for those who haven't run into this, we do the same thing for one @ for internal use only, but we have a number of clients who have added a bunch of @s that are localized to specific elements only. if I had done that, and want to regularize things for 2.0, how can I do that?
- Kris; that's something we'll really want to highlight in our migration notes, but not in the spec.
- Eric; probably the thing that people have fudged the most on, but now how do they integrate that work?
- Kris; I don't know how widespread this is. SDL did a tremendous amount of it. I also did a project with Scriptorium; they did it regularly.
- Nancy; I had clients who did the same thing.
- Kris; it's totally doable in DTD or RNG or XSD, it's just our rules said "for interoperability, you can't do this". any comments?
- Nancy; it clearly belongs in migration material, but not the spec; spec is what it is, not how to fix things.
- Kris; so this review will be open till Monday next week.


9. Continued: Appendix C content
https://lists.oasis-open.org/archives/dita/202208/msg00029.html (Eberlein, 16 August 2022)
Prototype of revised content:
https://lists.oasis-open.org/archives/dita/202208/msg00045.html
- Kris; original ask was for TC members to look at this content; followup is second link, with prototype for this content.
- Frank; shifting of coding examples makes sense to me.
- Gershon; should we combine apps C and D, or make one for DTD and one for RNG? I recommend we move info into coding practices.
- Robert; App C is what we used in coding our spec files, D is more of a tutorial on those constraints models.
- Gershon; maybe we should say in the title that App C is how we set up our files, and App D is something else.
- Scott; I like idea of dividing them by grammar type; you'll typically be working in one or other, not both.
- Robert; but they're already split up within the sections by grammar type.
- Kris; we could prototype this, but I used this structure because I didn't want to bury constraints and expansion models under coding practices. but people don't understand expansion or constraints, so I think we could keep that content at highest level in appendices, not buried. Maybe we need to highlight the fact that constraint examples are not just examples, they're really tutorials. all the examples in D, which I developed, went into 1.3 because no one seemed to understand how to do constraint modules. Then I did a parallel thing for expansion for 2.0. I know that examples about constraints for 1.3 have been widely used. We could prototype and see what it would look like for separating C into 2 secions, or merged C and D under high-level categories of DTD/RNG.
- Kris; comments on other aspects of this prototype? One open area is 3 kind of topics that were previously dumped into non-normative info. I could see dumping , 'if you're building a processor, here's what you should do' and we want to get rid of that kind of info. Wrt other 2 topics, do they really belong in non-normative section, or should they be in the spec proper.
- Gershon; I think those 3 could be part of coding practices.
- Robert; I don't think so; I don't think the material gets into practices, it's more theoretical.
- Gershon; so should it even be in the spec?
- Robert; I'm not sure about that; it's been here since 1.0. I'd need to look at actual content. don't know if it belongs.
- Gershon; and we've expanded the capabilities of DITA since it was written, so things may no longer apply... So I'd need to read this to see if we can delete.. wrt processing and interoperability, we might want to change name to make it 'formatting and p rocessing'
- Kris; formatting expectations are really very targetted; the other material talks about how procesors will get different results if they do resolution or conditional processing first. I wonder if some of that should not be buried in appendices, but be up front in spec.
- Gershon; maybe we can impose a precedence.
- Robert; that would break a lot of tools,
- Kris; I think we decided formally not to do that in 2.0.
- Robert; we wanted to do this, but no one was willing to do the work. and even then, ssetting aprecedence would have broken a lot of tools, which we didn't wan't to do in a 1.x release.
- Gershon; so we need to decide if we need to say this.
- Robert; we can't assume that new adopters know this.
- Gershon; then put it in its own appendix.
- Kris; we can do that, and we need to decide if any of this needs to be in normative body of spec.
- Dawn; so we all really need to read this section.


12 noon ET close





-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 13 September 2022

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2022-09-26 11:25:51



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