Groups - DITA TC Meeting Minutes 15 September 2020 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItems:  
1. Kris will fix spec source to correct example in bookowner.
2. Eliot will re-work proposal #33 (remove copy-to) in light of 9/15 discussion.. 
3. Kris will update stage 3 #351 and bring it back to TC.


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


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Stan Doherty, Kris Eberlein, Carlos Evia, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Eric Sirois, Dawn Stevens, Frank Wegmann


Business
========

1. Roll call
        Regrets: Stan Doherty 


2. Approve minutes from previous business meeting:
     08 September 2020
            X (Lawson,X September 2020) 
[holding till next week to give TC time to review]


3. Announcements
[no TC meetng next week because of ConVEX virtual conference]
 

4. Action items
[updates only; see agenda for complete list]
        18 June 2019
            Robert/Kris: Work on remaining stylesheet issues; see https://wiki.oasis-open.org/dita/stylesheetBacklog . IN PROGRESS 
- Robert; there was a bunch of stuff left, and have made a bunch of stylesheet fixes, htmlhelp and html; hopefully by next week, there will be just one plugin instead of  abunch
- Kris; I've also started to work on reducing complexity; I had done some stuff with the PDF plugin to reduce what we need to bare minimum.
        25 August 2020
            Carlos: Develop review schedule for !LwDITA spec 
- Kris; any updates?
- Carlos;  I need to contact you since you said you were going to do your spec, and I want to piggyback so we can have consistent formatting.


5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business discussed]


6. Review of DITA 2.0 proposal deadlines
        https://wiki.oasis-open.org/dita/DeadlinesDITA2.0 
[updates only; see link above for complete list]
Stage two
    (Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
        08 September 2020: TC discussion of revised version 
[see below agenda item #8]

Stage three
    (Stevens) New diagnostic element for troubleshooting (https://github.com/oasis-tcs/dita/issues/316)
        (./) 02 September 2020: Proposal to reviewers (Sirois, Harrison)
        03 September 2020: Feedback by reviewers completed
        ?: TC vote 
- Dawn; this can be ready for discussion next meeting, 9/29


7. E-mail to dita-comment
        Example in specs for bookowner is wrong (DITA 1.3 specs)
            https://lists.oasis-open.org/archives/dita-comment/202009/msg00000.html (Radu Coravu, 03 September 2020) 
Kris; this is a problem with the example for bookowner; I'll take care of it
***ActionItem: Kris will fix spec source to correct example in bookowner.


8. DITA 2.0 stage two proposals
        Vote
            None 
        Continuing discussion
            #33 Remove copy-to
                https://lists.oasis-open.org/archives/dita/202008/msg00040.html (Kimber, 25 August 2020) 
[continued from last week]
- Robert; I've been texting with Jarno, and his last comment was "the question is 'what's the point of removing this and replacing it with resource-id?' It  seems like no difference to me..."
Eliot; I don't agree with Jarno's characterization of using resource-id as 'grossly inelegant'.  I do think he has a good question.  It gets back to what Chris was saying also. Chris said we should have a way of embedding in content something that says 'this is what I want the anchor to be in some deliverable'. The logic is that this purpose is what we were using copy-to for, and we still need a way to do that, but we don't want to use copy-to. But we want to be able to say 'for this content, at this location, I want the anchor to be 'x'.'
- Chris; there should be a way for a procesor to take this anchor and turn it into a url; this should be an anchor.
- Eliot; I was starting to feel more like that as well. The question is; can we do that in a way that is architecturally cleaner, and doesn't repeat mistakes of copy-to?  I was thinking that resource-id or something like it would be better. Resource-id is meant to be used for identifying online help; this is the name by which that help is identified.  The reason resource-id is better than copy-to is that you can have any number of them, and can better ID them, that gives us a way to have a persistent identifier that can be used, but isn't a direct specification of the target.  It doesn't avoid the issue  multiple copies, in which case there will be multiple copies in the deliverable.  Without something like resource-id, you'd have to do something completely custom, or have to use keys, and that will still be specific to your processor.  We want something that's processor independent.  We want to use it, but only use it in a map, so we say, for this purpose, you must use resource-id in this way. because it has a tight connection to help systems. I'm hesitant to expand it's use beyond that. Anyone know if there are help delivery systems that use it the  way it was intended?
- Kris; quite a few use it.
- Eliot; so my concerns about usurping that mechanism are well-founded.  So I'd suggest we define something just like resource-id, so we can specify what IDs you want for what outputs, so you can have multiple IDs that are target-specific, to specify the result anchor. and we should stipulate that it must be done exclusively in maps.
- Robert; seems a bit gross, I think it would be hard to define a new element that's unique enough to work.
- Chris; resource-id for a help system is exactly what we're talking about, so we don't need to disambiguate it
- Eliot; so you wouldn't have a problem with it if I had to add that usage?
- Chris; if I'm using resource-id for help, now my help output is embedding things in my other outputs.
- Robert; resource-id already allows multiple instances for different outputs; it's meant to be there multiple times for different help systems. 
- Kris; how do we handle precedence between resource-id's defined in a map and in a topic?
- Robert; resource-id cascades into the topic from map.
- Chris; and resolution will be processor-dependent, which is correct.
- Dawn; we just had this situation come up; a client moving out of SDL to Astoria; resource-ids went to guids, we had to write code to do 'if an app-id, use that, if there's a guid, use that, if neither, use filename'.  
- Eliot; so it sounds as if using resource-id for this isn't a concern; you can use it the way we've just described, the way you were using copy-to.  It doesn't remove the need for processors to do something, but gives them a common basis to work on.  I'll update the proposal to use this as the solution.
- Chris; the difference boils down to architectural purity; copy-to was a hack, resource-id operates the same way, but it was meant to do this.
- Kris; I'd like to hear back from Robert, and how he thinks Jarno will respond.
- Robert; Jarno has 'the artisanal vegan' perspective;  how do we describe this?  E.g., "processors 'can' do this", or what?  Without that, we haven't provided a migration path for anyone.
- Chris; the text from the current spec might be perfect; it describes the feature, so outside of the migration guide, we shouldn't add anything else, and we'll need to put a bunch of stuff in the migration guide.
- Robert; but if the migration guide makes a suggestion, it has no force...
- Eliot; we already have a list of suggested values for deliverytarget; we can reuse those; if you have more than that, you have to come up with your own
- Chris; also, for unqualified app names, processors can and should use the unqualified app name as target app_id but without an app name, as the default.
- Kris; what next? any more investigation at TC level, or can we send Eliot back to do a new proposal?
- Robert; let's send him back for a new proposal; I've sent Jarno notes from this discussion; he'll reply if he has comments.
- Kris; Eliot, can you revise the proposal?
- Eliot; I can turn it around by next meeting.
***ActionItem: Eliot will re-work proposal #33 (remove copy-to). 
- Kris; come back to the list if you need any help. Any other  thoghhts or comments?
[none, continued to next week]


9. DITA 2.0 stage three proposals
        Vote 				None 
        Continuing discussion	None 
        Initial discussion		None 
        Early feedback		None 


10. Continuing: Wondering how many people use the data-about element
        https://lists.oasis-open.org/archives/dita/202009/msg00013.html (Anderson, 01 September 2020)
            Update from thread on dita-users list 
- Kris; I've posted to dita-users asking this question, all responses were "we don't use it, we don't understand it, it's not a good idea..."  So I think we can move ahead with a stage 2 proposal for removing it.
[Eric, Eliot, and Carsten will be reviewers, whoever gets back first is 'the' reviewer.]


11. Key resolution, key text, and local fallback
        https://lists.oasis-open.org/archives/dita/202009/msg00007.html (Eberlein, 01 September 2020) 
- Chris; there are 2 issues; 
1) on multimedia elements, @type specifies a mime type of multimedia element being addressed; we have no other place in DITA that specifies a mime type; other things specify DITA elements. So, when you have a media element that references a resource by key, DITA doens't have an @ that's really suited for specifying a mime type, (maybe @format???) We need to discuss this.  if you reference a media object with a mime type, how do you find the mime type?
Should a keydef specify a mime type? or should a processor 'intuit' the mime type from the token?
- Eliot e.g. if I say @format="jpeg"
- Chris; if @type is a mime type, we'll need to use something else to specify more info. 
- Eliot; I'd say 'it's up to processor to determine mime type', but thats not really helpful.  But @format on a topicref gets used for a number of things, some of which map to mime type, some of which don't...
- Chris; I thought @type held the eleement name, and @format ="dita"
- Eliot; we could say value of @type would be mime type, and then let the resource tell you what its mime type is...
- Chris; that lets you supply a number of different foramats, and @format tells you its mime type.
- Kris; if an explicit mime type isn't given in @format, processors can use a file extension to determine the mime type.  I think the current language covers us; we may also need to specify it somewhere where we're discussing multimedia references, but we do have something there in both audio and video. So Chris, do you think that's adequately covered?
- Chris; I think that's fine.
- Kris; I think our element references are good to go; do we need to highlight it in out architectural spec?
- Chris; yes we do, and a reference by key, with mime type not specified, would be useful.
- Eliot; the general definition of @type doesn't say anything...
- Kris; @type has a lot of definitions, and audio/video mention that their @type is different from the standard definition of @type.
- Eliot; if I say @type="jpeg", what in the spec supports that?  Would be useful to talk about that case, when @type is used to reference non-DITA resources, that could be a mime type.
- Chris; but it's a radically different semantic for same @.
- Eliot; but the spec already mentions what to do when referencing DITA content, so we could say what it means.
- Chris; @type means different things on different elements; now we're saying it means different tings on the same content; that bothers me.  Every DITA resource, because it's a resource, has a mime type...
- Eliot; whould we change @type to @format on those elements?
- Chris; I like the idea of using @format instead of @type for the elements, it makes it more consistent, and it would be good if we add that @format can be a mime type on all referencing elements.
- Eliot; I agree.
- Robert; I agree too.
Kris; so how should we handle this; do we need a proposal? not just updating media proposal?
- Eliot; why?
- Kris; if we're talking about @type in other locations, we'd have to have another proposal... 
- Robert; it would be cleaner, but it doesn't help us any, so why do it?
- Kris; the most expedient way is to modify #351 to specify @format rather than @type, and then just fix the @format, or we could fold changes to @format into #351
- Robert; #351 needs to change
***ActionItem: Kris will update stage 3 #351 and bring it back to TC.


12. type attr, keydef element, and multimedia elements
        https://lists.oasis-open.org/archives/dita/202009/msg00008.html (Eberlein, 01 September 2020) 
[11 & 12 are related; see discussion above]


12 noon ET close 

        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 15 September 2020

---

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: 2020-09-28 17:26:46