dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 10 January 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Mon, 16 Jan 2023 07:03:11 +0000 (UTC)
Submitter's message
ActionItems:
1. Eliot will come up with some examples the spec should have around rules for processing cascading @ values. He will clarify description of @scope in this context as well.
2. Frank will bring TC's formal reponse wrt specialization in LwD, and LwD use of the data element, back to the next LwD SC mtg.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 10 January 2023
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
===========
Robert Anderson, Tammy Crowley, Stan Doherty, Kris Eberlein, Nancy Harrison, Eliot Kimber, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy, Todd Thorner
Business
========
1. Roll call
Regrets: Scott Hudson, Keith Schengili-Roberts, Kathryn Torriano
2. Approve minutes from previous business meeting:
20 December 2022
https://lists.oasis-open.org/archives/dita/202301/msg00002.html (Harrison, 06 January 2022)
Kris moved, 2nd Dawn, approved by TC
3. Announcements - none
4. Action items and volunteer tasks
[updates only; see agenda for complete list]
)
20 December 2022
Robert: Implement impose-role proposal COMPLETED
- Robert; this is done
Spec reviews:
Dawn: Examples for general task and
Dawn: Examples for reference (architectural topic) and
- Dawn; not done yet, but I expect to work on it next week.
5. Schedule for January 2023 reviews
https://lists.oasis-open.org/archives/dita/202212/msg00029.html (Eberlein, 20 December 2022)
- Kris; everyone please block out time for these.
6. Technical content review C: Programming, software, and UI domains
https://lists.oasis-open.org/archives/dita/202301/msg00005.html (Anderson, 09 January 2023)
- Robert; this is opening now, please note how we want comments recorded; with draft-comment elements rather than Oxygen comments. If you have a comment on a comment, edit the original comment rather than making a new comment.
- Kris; and please remember; review the PDF, then open the source and add comments in ContentFusion (CF). CF will introduce formatting errors, so reviewing it there isn't accurate.
7. Editorial work on DITA for Technical Content 2.0 element-reference topics
Topic cluster assignments
https://lists.oasis-open.org/archives/dita/202212/msg00027.html (20 December 2022)
Recording of 20 December 2022 session
https://lists.oasis-open.org/archives/dita/202212/msg00033.html
GitHub education that the TC did in 2018
https://lists.oasis-open.org/archives/dita/202212/msg00034.html (Eberlein, 21 December 2022)
Have volunteers forked the repo?
https://lists.oasis-open.org/archives/dita/202301/msg00000.html (Eberlein, 04 January 2023)
- Kris; I use github for pull reqs, and the command line for pulls and commits. We need for all volunteers to review their work to be done; next week, I'll ask for estimates for when this work will be completed, hopefully all by March?
8. Rework of cascading processing rules
https://lists.oasis-open.org/archives/dita/202212/msg00031.html (Kimber, 20 December 2022)
https://lists.oasis-open.org/archives/dita/202301/msg00001.html (Eberlein, 04 January 2023)
- Eliot; I've reworked the rules in a non-procedural way. So, for an element to which a value may cascade, we describe 'here's how you determine what the effective value will be'. This changes the focus from 'how do I push the values down?', to 'how do I determine what my value should be?'. So we're looking at ancestry.
- Kris; do folks have questions? Robert or Eric, any comments? My point is that it seems we're introducing new terminology, specifically 'direct' and 'merged' as they apply values of attributes. It would be nice to avoid that; but if we can't, we can't.
- Eliot; these terms 'direct' and 'merge' come from the way the process is currently described. Something either has a value or it doesn't; if the values cascade, then values are merged. The term 'merged' is implied by a cascade value of "merged.'
- Kris; if we define what a merged @ value means, it might be better.
- Eliot; it might not be set at a higher level; it could also be set on the lower level. The issues is understanding whether you're using the value of an ancestor, or self.
- Robert; the issue is that it starts with the map tree that resolves all references, and in some cases you have to determine all the @s to figure out what the value is. If you haven't figured out the value of the @scope everywhere, you don't know what the value is. This isn't a problem with your email, I think this is what it just is.
- Eliot; I see that you have to determine the effective value of @scope, to figure out value of map references, then you need to apply cascading to figure out the actual values. Because @scope determines what maps get resolved, it has to be treated as a special case.
- Robert; I'm not sure whether any other @s need to be treated as a special case.
- Eliot; to Kris's question, from an XML processing standpoint, there's no difference between defining an @ value in the source or in grammar files. It can be defaulted either place. The parser just takes care of precedence. it's not something to be worried about or controlled.
- Eliot; wrt what examples we need for this, I'll have to think about that.
- Kris; what we had in 1.3 spec might point to what examples would be helpful.
- Eliot; I'll go back and look at those; there are some challenging edge cases. e.g., a mapref can refer to a subparticle map...
- Kris; that's a detail a lot of folks forget; it's not common, and especially once we remove topicset and topicsetref, it will be even less common.
- Eliot; but some folks might have used those previously, and they'd need to know how to migrate them.
***ActionItem: Eliot will come up with some examples the spec should have.
Eliot; I also have an ActionItem for clarifying @scope as well
***ActionItem: Eliot will clarify description of @scope in this context as well.
- Tammy; I'll spend time looking thru this and the original version, then I'll see what is confusing.
9. LwDITA concerns
Need to make decisions around LwDITA and specialization
https://lists.oasis-open.org/archives/dita/202212/msg00026.html (Eberlein, 20 December 2022)
- Kris; I've been bringing this up at LwD meetings since Sept, but I think TC input is important. The question is 'is specialization for XDITA? for HDITA? And if it's for XDITA, is it for all DITA elements, or only a subset? It's clearly not for MDITA. Currently, grammar files only uses entities for certain things, which precludes specialization for any others. But is it supported for all elements, or just a subset? And if a subset, which ones? And if so, what's the markup for that? there's some markup suggested for keytext and note.
- Stan; what would be the use case for specializing LwD?
- Frank; use case is if LwD is a variant of DITA, then specialization is a feature of DITA, so LwD needs to have it as well. But it's one thing to postulate it, and another thing to formulate it. LwD SC has to decide what to do, and how to do it.
- Eliot; it always seemed to me that benefits of LwD was that it had a simplified profile that avoided the complications of DITA processing. That would suggest that it would be better to avoid specialization so that an LwD proessor didn't have to worry about it.
- Frank; and you're welcome to put that forward to LwD meeting. that's a good point to raise.
- Eliot; LwD has always been strange; LwD is inherent in DITA, OTOH, it's useful to have it be defined as soemthing that's maximally simple but still useful.
- Kris; I'm not sure I have a dog in this fight. My work on LwD came up from my insistence that there be reuse between the core DITA and the LwD specs. So as I did reuse work, I saw the problems, for example with the data element. I just want LwD to make a decision and stick with it.
- Dawn; I agree.
- Kris; I think it does get a bit ugly to have to try to work thru patterns for HDITA and/or MDITA
- Eliot; for me, that's a compelling argument so that you can have a correspondence between those 3 syntaxes. If I have an LwD doc and want to speciialize it, then I should just call it DITA and use full DITA; document doesn't have to change, just the processor.
- Tammy; so they're trying to add more functionality to LwD?
- Frank; for LwD SC, either they need to get resources to really define the concept and functionality of specialization in LwD, or they need to scrap it and say it's not a feature of LwD anymore.
- Stan; a few years back, Michael P. had proposed an alternate method of templating for LwD in the SC, then we pulled that requirement out of the original requirements doc. So the meaning of specialization we have in DITA is not what they have
- Kris; templating was scrapped?
- Stan; it was deferred, not scrapped.
- Frank; I don't feel responsible for it.
- Kris; let's continue this next week.
LwDITA and elements in
https://lists.oasis-open.org/archives/dita/202212/msg00035.html (Eberlein, 22 December 2022)
- Kris; problem here is related to how we define rendering expectations for data, which we've always said processors should treat as an unknown data element, and should not render it. That conflicts with the LwD usage of data as a general purpose data element, such as author or user-role. There are probably only 2 ways to resolve the conflict;
1) LwD could use a different element for this purpose, like othermeta, or
2) as the TC, we would need to redefine data. I need to hear from the TC so I can bring the decision back to LwD SC.
- Tammy; so LwD wants data to be rendered?
- Kris; if they're using it as an all-purpose element, thenyes they want it to be rendered.
- Robert; given how data is defined, it would be hard to declare a mapping of that to a simple thing, because data is a very complex element. Unless they redefine it to be simple, I don't know how the mapping could take place. It's not an obvious thing; in addition, the larger issue is that LwD is supposed to be a subset of regular DITA, so if you use a LwD document in a full DITA implementation, it should just work. But if their definition of an element is broader than regular DITA, rather than a subset, that won't work.
- Kris; that's at the heart of my concern too. I think we have to say that using data this way isn't workable, and suggest that LwD use othermeta instead.
- Dawn; I agree with that.
- Nancy; me too.
- Robert; is there a statement somewhere of what LwD does with this?
- Kris; not 100%; I haven't gotten any responses from LwD Sc, but based on examples and wording of CN, and mappings between LwD and HDITA and MDITA, seems to be clearly expected to be metadata that is rendered in output.
- Frank; I'd agree, I wasn't there when they drafted the topic. But given that LwD is a subset of DITA, we'll have to resolve this in next LwD meeting. There might be something even better than othermeta for this, in order to make LwD compatible.
- Kris; we also need to expect that processors will handle elements in LwD topics and full DITA topics the same way when they're in the same place. Michael might have realized that data could be in prolog when othermeta could not, and so put it in. without realizing all the implications.
***ActionItem: Frank will bring TC's formal reponse to next LwD SC mtg.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]