Groups - DITA TC Meeting Minutes 25 Januaryr 2022 uploaded

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

        Submitter's message
        ActionItems: 
1. Kris and Robert will set up a mtg with Frank about LwD issues
2. Frank will reach out the L10N dept. at his company about usage of translatable content in othermeta @s


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


Attendance:
Robert Anderson, Carten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann


Business
========

1. Roll call
        Regrets: none


2. Approve minutes from previous business meeting:
      15 December 2020
        18 January 2022
            https://www.oasis-open.org/apps/org/workgroup/dita/download.php/69546/dita-tc-minutes-2022-01-18.txt (Kimber, 25 January 2022) 
[held for attendance]


3. Announcements
        none


4. Action items
[updates only; see agenda for complete list]
        14 December 2021
            Frank, Kris, Robert: Consider usage of the many ways that we refer in the spec to something being determined by an implementation IN PROGRESS 


5. Report from LwDITA subcommittee (Wegmann)
- Frank; met yesterday, as yet nothing on spec front; I'm a bit flooded; but we had discussions on specializations and LwD, and how we need to provide some examples outside of spec just to get folks clear on what these concepts mean.  Yesterday, worked on how to nest sections in LwD.  Jennifer reported how she does them at IBM; gen'l agreement was that we stick to the way we've defined it previously; i.e., if you want to nest, use a DITA map mechanism, otherwise it will lead to confusion. The approach that Jennifer chose was different; discussion was how can we meet a common ground?  We want to make it compatible with current implementation; so we'll be discussing that topic next time as well.
- Kris; any questions?
[none]
- Kris; we want to encourage SC to stop considering new features or things to do, and work on spec, so you're not looking at a moving target.
- Frank; we're on the same page on that, we don't see any change to our current set of features, but discussion went as it went... I'd like to touch base with Kris and Robert to have a deeper understanding on what we need to do.
- Kris; happy to do so, and walk you thru structure of how those patterns are set up.
***ActionItem: Kris and Robert will set up a mtg with Frank


6. Review G: Metadata elements
        Opening of review: https://lists.oasis-open.org/archives/dita/202201/msg00016.html (Eberlein, 11 January 2022)
        Status: https://lists.oasis-open.org/archives/dita/202201/msg00027.html (Eberlein, 18 January 2022)
        Questions emerging in the review of the metadata elements
            https://lists.oasis-open.org/archives/dita/202201/msg00026.html (Eberlein, 17 January 2022) 
        NEW Mentioning Dublin Core in the "Usage information" sections
            https://lists.oasis-open.org/archives/dita/202201/msg00036.html (Eberlein, 20 January 2022)
                https://lists.oasis-open.org/archives/dita/202201/msg00037.html (Joseph, 23 January 2022) 
- Kris; Gershon, the comment about Dublin Core (DC) came from you to begin with; last TC call had gen'l ambivalence. please give us more context.
- Gershon; seems a bit odd that we're noting euivalences; usually the spec says 'this is how you use it' or gives a reference to another spec (e.g., 'go there for more info').  I did see Robert's email about DC being 'hot at the time,' but wondering if modern users will care about DC; they probably won't.  If we want to use it, we should just ref. it as is, otherwise just give our own usage.  It seems to give little value.
- Kris; there's a precedent for this, we do similar things with video elements wrt HTML5 elements.
- Gershon; I think we just reference the HTML5 elements e.g.,  'for more info, just see HTML5 ref'.
- Kris; the problem is that there are multiple versions of DC; the 'official' one is only available if you pay for it.
- Robert; I think we should just reference it; when we did it, everyone thought it would become a defacto standard, but it never did, so we don't need to have it in now. 
- Kris; any objections to removing it?
- Keith; I'm wondering if some of the basis for adding those metadata elements was DC.  If so, is there a point in keeping the ones for which DC was the sole basis for their addition?  There seem to be some instances that have no relevance to anything else... So why keep them? 
- Robert; the only places we mention DC are author, critdates, category, and copyright.  Of those, only category seems superfluous.
- Kris; I think category is still in use, where folks have tried to link up taxonomy with their subjectscheme.
- Robert; so Keith, that was a good question, but I don't think there are any elements we could trash.
- Keith; if there was anything that was specific to DC we could drop it, but I agree that we probably should keep them
- Kris; my sense is that those elements are all being used.  We want to look very carefully at what we remove, in order to avoid huge migration costs.
- Keith; agree
- Kris; any other comments?
- Nancy; so are we going to put the the DC references someplace else, or just take them out?
- Kris; just take them out.
 
       NEW Improve content model of othermeta
            https://lists.oasis-open.org/archives/dita/202201/msg00038.html (Joseph, 23 January 2022) 
- Gershon; I suggest a proposal to make a small change; either replace content @a with content sub-elements, or allow @content within othermeta for translation purposes.  Of course stage 2 &   3 of the proposal would delve into other implications. I would do the work on the proposal.
- Kris; I've never seen people using @content to hold a translateable string, it's usually a named-value pair that maps to someone's tool set.
- Robert; I've seen it used, but don't remember whether the use ended up with a translateable string in the content.  Just fyi,  @translate-content has been in there from 1.0. This topic came up once before, but I can't find a record of why we decided to keep it.  If we change it, I don't want to introduce a new element, especially not one called 'content.'  What we have takes it a bit further away from HTML markup, but not too badly, I think. 
- Gershon; I'd be ok if we removed @trannslatable-content, that would work for me also.
- Robert; it would be simpler, but it would break things for the many peole already using it.
- Gershon; but they could just specialize it.
- Robert; but that's not trivial, to replace something that anyone can do today.
- Gershon; maybe we could send to user groups to see if there is any usage; if no one's doing it, we probably could remove @, otherwise we could do soemthing else.
- Kris; I don't think we always get the best responses from that, especially since the folks concerned the most are translation vendors, not authors or IAs.
- Eric; I have a client who uses that @, but only for non-translateable stuff.
- Frank; that's more or less the way we use it as well. we use it only for non-translatable stuff; I wonder if anyone would ever put translatable content in there, and I think they'd also tell the translation vendor to pay attention.
- Kris; I worry about making changes to othermeta; it's always been the fallback for other things; it existed before we added data. If we change this, I think we create a lot of problems for people with very little benefit. I think if people are needing to translate metadata, they're probably using data instead.
- Gershon; well, we hope they're using data
- Kris; I've specialized from othermeta because it's easy to do and to set up subjectscheme values.
- Gershon; my concern is that we don't want to have translatable content in @s; if folks aren't doing it, then removing it won;t hurt. if folks are using it for that, we should do nothing now and deprecate it for 3.0.
- Kris; so either remove the @ or leave content model as is.
- Robert; most of us aren't aware of using it for translations, but if there are and they're not having a problem, we'd be breaking their models with no benefit.
- Gershon; well, we're hoping to help them understand best practices.
- Robert; so we break their content with no replacement.
- Kris; very few people who care will see this on dita-users; if we need to do any more research, we shouldn't post on dita-users, but reach out to translation vendors.
- Gershon; we always tell vendors 'don't translate @ values'; if they do put translatable content in @s, we work with authors, not vendors.
- Kris; I think we should leave this one alone, because we could incur a lot of cost with very little benefit. Eric, Frank, any comments?
- Robert; I can't speak to translation tools, but do not expect translators to read the spec; I think translation tool vendors will read it, we list this as a translatable @, so they could see it as such.
- Frank; maybe I should contact our L10N dept to see how they deal witht this, but I would leave it as it is right now.
***ActionItem: Frank will reach out the L10N dept. at his company
- Kris; any coments?
- Nancy; I think we should investigate it, but at the most just deprecate it till 3.0.
- Kris; let's leave it till next week.


7. Review H: Chunking
        https://lists.oasis-open.org/archives/dita/202201/msg00031.html (Eberlein, 18 January 2022)
        NEW Questions from review:
            https://lists.oasis-open.org/archives/dita/202201/msg00039.html (Eberlein, 25 January 2022) 
- Kris; wrt chunk="combine" on topic prolog metadata, spec says nothing about this.
- Robert; I apologize for not doing chunking review; the spec description of chunking with prolog accurately reflacts DITA-OT behavior. But I'd hesitate to say that losing that data should happen.
- Eliot; losing data should always be a bug..
- Robert; I'm not sure it's thrown away, but when the rendering is in HTML, it's going off of prolog from root topic.
- Kris; maybe we just want to say chunking processing is implementation-specific.
- Eliot; true, but not that helpful. e.g. in PDF, there's no place to put metadata from a topic, it's completely lost.
- Kris; that's true.  Stan, what about simply leaving it alone?
- Stan; we can leave it in, but maybe we should give people a heads-up of some sort, that would be nice.
- Eliot; my objection is that that's just one of a huge number of concerns about chunking; there are a whole lot of issues from the rendition POV that are affected by chunking.
- Kris; the point is very useful for a company's implmentation guide, but not something to put in the spec.
- Stan; do we say that in the spec?
- Kris; we do not, and we haven't yet reviewed yet what there is in the architecture topics on metadata.
- Zoe; I brought this up last week, so when we get to arch. side, we need to discuss it. I know everything is implementation-specific, but for metadata, we need to be more specific about it being implementation-specific.
- Kris; so this will come up again when we do review of architecture content on metadata, but we can leave it alone in this content about chumking.
- Kris; wrt other questions raised in mail:
question 2. - answer is 'no'
question 3. - creating individual glossary files for each definition of a glossterm
- Zoe; also for question 3, some sort of generated error messages, a topic that pulls in all error mesages and delivers individual messages.
- Robert; think that's the only experieance I have of seeing the split, many small items put together in one chunk.  Wrt question 4 - processors naming schemes for chunking - I don't know what we should say about getting predictable file names using keys.
- Dawn; this was my comment/question, and I think if there's an example, that may be all we need to do.  It's been a problem for my clients that do a lot of chunking, if file names change every time.  I wonder if there's some way to help people to know that if they need a predictable file name, there are ways, using keys, to get it. 
- Eliot; and don't forget our resourceid mechanism, so we might just point to resourceid as a way to provide hints about your output, and processors can use keys as a way as well, but spec doesn't specify or require either.
- Dawn; it will help me to read all resourceid stuff.
- Eliot; because resourceid is now a replacement for copy-to. 
- Robert; file naming is left up to the processor; if it's giving you the wrong thing, contact your processor.  But one response would be that if you're trying to use the same content in multiple parts of your map, you'll get file naming issues.
- Dawn; their problem is that they have it in a map, which creates chunks 1 2 3 4 5, if they then process it again to make an update, it gets random names.
- Robert; that's a tool decision, don't know why a tool would do that.
- Kris; are you getting rid of all your temp files in between updates?
- Robert; it's also possible you've referenced it somewhere in doc where it's not chunked; in which case the toolkit thinks it's unable to preserve the filename because it's already in use.
- Dawn; we are using the toolkit. you've given me some ways to think about it. 
- Eliot; also, the new version of toolkit has an extension point that makes it easy to specify target filenames.
- Kris; we're still working on chunking review.


12 noon ET close 




        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 25 Januaryr 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-01-31 11:03:54