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 6 March 2018 uploaded


Submitter's message
ActionItems: no new items



=================================================
Minutes of the OASIS DITA TC
Tuesday, 6 March 2018
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Kris Eberlein, Carlos Evia, Richard Hamilton, Nancy Harrison, Alan Hauser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Eric Sirois, Dawn Stevens, Jim Tivy, Maria Essig


Business
========
1. Roll call
Regrets: Bob Thomas

2. Approve minutes from previous business meeting:
27 February 2018:
https://lists.oasis-open.org/archives/dita/201803/msg00013.html (Harrison, 05 March 2018)
[vote next week; minutes went out late]


3. Announcements:
New TC members: None


4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
19 September 2017:
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
30 January 2018
Anderson: Stage two proposals for issue #18: Make audience, platform, product, otherprops into specializations
[completed]
13 February 2018
Kris and Bob: Fix style sheets to produce OASIS-requested formatting changes (IN PROGRESS)
26 February 2018:
Nitchie: Stage 3 proposal for issue #27: Add multimedia domain
- Chris; still backed up
- Kris; will take it off agenda
27 February 2018
Bob: Upload PDF style sheet changes to GitHub (COMPLETED)
13 March 2018:
Kimber: Stage 2 proposal for #34: Remove topicset and topicsetref
Kimber: Stage 2 proposal for #21: Resolve inconsistent class values for shortdesc, linktext, searchtitle
Thomas: Stage 2 proposal for issue #13: Split base and technical content


5. "LwDITA: An Introduction" committee note
New package: https://www.oasis-open.org/apps/org/workgroup/dita/document.php?document_id=62491&referring_url=%2Fkws
Progress?
Public review requested on 14 February 2018
15-day public review announced on 23 February 2018: https://lists.oasis-open.org/archives/dita/201802/msg00069.html
- Kris; any updates?
- Carlos; SC met yesterday, we will use the same response to comments for public review #1 as for #2. We discussed new comments, but there don't seem to be any new ones; we've already incorporated responses to all previous ones.


6. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
Update:
TC admin provided list of cover page corrections on 06 February 2018
Source changes implemented:
https://lists.oasis-open.org/archives/dita/201802/msg00036.html (Eberlein, 09 Feb 2018)
Style sheet changes needed:
https://lists.oasis-open.org/archives/dita/201802/msg00040.html (Eberlein, 13 Feb 2018)
Progress?
Schedule
https://wiki.oasis-open.org/dita/DITA-1.3-errata-02-schedule
- Kris; bob has uploaded changes to stylesheets. won't be able to do
who can help with html transform
- Nancy; I'll try again to see if I can process the spec with a new tool version installed.
- Alan; what are the changes required?
- Kris; I'm not really sure what are required, I'd have to look and see. I've had mmuch less involvement with HTML than with PDF.
- Alan; I'm busy, but if you want to send me info...
- Kris; ok, we really need robust stylesheets, I don't want this to happen again.


7. DITA 2.0 stage three proposals
Vote
None
Initial discussion
a. Issue #17: Make outputclass universal
https://lists.oasis-open.org/archives/dita/201802/msg00105.html (Anderson, 28 February 2018)
Robert gave an intro: This is pretty straightforward; @outputclass is already on most of our elements, but a bunch are missing it, including some that need it. The technical implementation is also straightforward, but with wide impact. A lot of elements need to have their @ statement changed, plus moving discussion of @outputclass into univ-atts section. Grammar changes are a little more complicated; many elements have @outputclass defined separately; they need to have those discussions removed, since it will be in univ-atts. Dawn noted that it's not illegal to define an @ twice, but it will give a warning, and given how ubiquitous @outputclass is, authors will not like it; that's where the migration guide will need to help. I'm not sure about updating the grammar for users; a search-replace tool will probably do most of work in migration.
- Eliot; I'm looking at the proposal to remove xtrc/xtrf @global-atts; would it make more sense to replace what's now in global-atts with @outputclass?
- Robert; global-atts is on dita container element, which doesn't haven't anything else. we'd have to change that for dita element, which could be a problem.
- Eliot; so does xtrc/xtrf proposal remove global-atts?
- Robert; yes, essentially.
- Eliot; then I withdraw my suggestion.
- Kris; in your section on 'Migration Plans' list item #2, you're suggesting using trang to convert modular DTDs, XSDs and RNG files to a single monolithic RNG file, right?
- Robert; that's what I suggest; to convert everything to RNG using trang.
- Kris; Trang doesn't currently do that. I'd like to bring up to TC at another time how we can get monolithic DTDs from modular using trang or other tools.
- Eliot; I'm not sure it's possible to have a single xsd, because of the need to use #redefine...
- Robert; but once it's monolithic, you don't need #redefine.
- Eliot; true
- Robert; so a useful wording tweak would be to remove word 'single' modifying 'file' from the suggested instructions.
- Eric; there's also a monolithic XSD issue, but not specific to this issue, we can discuss at another time.
- Kris; we will move forward for stage 3 vote next week

b. Issue #36: Remove deprecated items
https://lists.oasis-open.org/archives/dita/201803/msg00008.html (Eberlein, 02 March 2018)
Kris; this was reviewed by Stan and Robert; I've addressed their issues. We've discussed this a lot; it requires changes to a number of modules (see list in proposal). The proposal doesn't include all the changes to RNG and XSD. The changes to the spec are fairly extensive (topics to change are listed in proposal). There's also a table with specific changes under section 'Modified Specification Documentation'. Wrt migration plans, 'Migration Plans ...' section has a table listing all changes needed, explains a strategy to use for migrating, and includes samples of corresponding 1.3/2.0 markup. Proposal doesn't include guidance for @ that were specified 'for future use' since we don't know what people used them for. Also, there are no suggestions for what to do with directly modified DITA module files rather than doc shells, since we have recommended them since DITA 1.1.
- Kris; any comments, thoughts from reviewers?
[none]
- Kris; any discussion?
[gen'l approval]
- Kris; I want to move this, so we can give users the longest possible runway to get ready for these changes.
- Kris; we will move forward for stage 3 vote next week

c. Issue #46: Remove xtrf and xtrc attributes
https://lists.oasis-open.org/archives/dita/201803/msg00016.html (Anderson, 06 March 2018)
Robert; this removes stuff that should never have been there; also lets us get rid of global-atts, which also should never have been there. The removal in grammar files is straightforward; just remove the declaration of global-atts, and do a search-and-replace in all elements. For spec, it's also straightforwad; just a few topics directly reference the global-atts @, plus we need to remove the topic in the spec that defines the group. If folks still want it, they can create a specialization to get that, though the better option is to use something similar, but choose an @ name that is more meaningful.
- Nancy; does the processing still create and use them?
- Robert; yes, it does
- Kris; any concerns?
[none]
- Kris; we will move forward for stage 3 vote next week


8. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
Issue # 08: New element for inclusion of content from external files
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/62589/Issue08-include.html (Nitchie, 25 February 2018)
Chris; at our last discussion, we closed as Eliot was in middle of saying something.
- Eliot; wrt conref, you can implement processors that will return content using URLs and a transform to create DITA out of referenced content; e.g. getting a table by ref. From that standpoint, it makes sense to model those cases of reusing data; if the goal is to have the end result be normal DITA markup, the best way is to just use conref and have processing resolve it.
- Chris; I disagree. first reason; conref is DITA-specific, for transcluding DITA markup; to use if for things that aren't DITA requires breaking it. If we use conref for this, we're limited to conref @s, which could be very limiting. @parse gives you at least a secondary option to specialize processing. but conref is for embedding DITA content, not non-XML content.
- Tom; question; what impact does including non-DITA content via conref have on conref DITA markup? Is there extra markup weight there?
- Eliot; no; conref is either keyref or a URL. I always do it thru keyrefs, and the keydef is where all the complexity is, e.g via metadata elements. I disagrree with Chris; I don't think it makes conref more difficult; it just makes the keydef more complex.
- Kris; I like Chris's proposal; it's elegant, straightgforward, and it makes clear that there's a difference between reusing DITA content w/conref and reusing non-DITA content.
- Tom; my objection would be that in Chris's proposal the include element is already being overloaded by 1) unifying XML-ish refs and 2) handling non-XML tranclusion. Should there be a 3rd kind, to serve the purpose of bringing in things that are not XML, but making them DITA inside DITA content?
- Eliot; I suggest that conref can already be used for that today. I'm not objecting to the proposal as currently written; I'm objecting to extending the semantics of @parse to generate normal DITA markup from non-DITA data, as per Chris's suggestion that we extend parse @ to do more in the future.
- Chris; I'm making an sxplicit distinction between DITA-and non-DITA content, conref for former, include for latter. Once I reailzed you needed a wrapper for each of svgref, mathmlref and coderef, to provide context, it seemed like a no-brainer to have a generic wrapper element. I'm considering source format of source when deciding how to transcluse. Eliot is considering output when deciding how to transclude.
- Robert; I don't like that. It gets back to the idea that the TC takes a stance that the spec doesn't say what you can/should do with your content, just, if you have it, processors need to do certain things with it. I'm considering the final repreentation of something.
- Chris; so, what side are you on?
- Robert; I think you should be able to refer to the content here as text or XML, but how it gets renderd depends on the processor.
- Kris; so Eliot, is your major concern with the possible extension of values for parse @? and what processors may do with it?
- Eliot; yes; I'm happy with the proposal as long as values for @parse are only text and xml, and no reference made to extending them..
- Robert; I disagree. we've already extended conref to do extra stuff
- Eliot; we can let tools support any values of @parse they want, we can't limit what tools can do. My concern is with us adding values in the standard that are conref-like; that creates requirements that are huge and unbounded.
- Kris; so in the description of @parse, do you support the text 'Processors may support additional values for @parse with custom processing expectations.'? but oppose . 'Other standard tokens may be added in future versions of the DITA standard'?
- Eliot; exactly, I think we should not say that.
- Robert; I agree; many statements relating to 'future use' have not happened in 15 years.
- Chris; I can take that out
- Eliot; I also object to the way the paragraph under xml is written; it presumes a processing approach. 'to which processing is expected to be applied.' We need to amke sure we way it in a way that doesn't presume a processing model.
- Chris; intent is to continue the way we do it now.
- Eliot; that presumes a way of precessing.
- Kris; I think you're treating this like a stage 3 proposal, but it's not. Are we ready to vote, or do you want changes in order to vote?
- Eliot; I don't need changes in it to move it forward to stage 3.
[moved to vote next week]


11:58am ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 6 March 2018

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: 2018-03-06 10:14:36



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