https://lists.oasis-open.org/archives/dita/201906/msg00026.html (Hudson, 10 June 2019)
https://lists.oasis-open.org/archives/dita/201906/msg00027.html (Kimber, 10 June 2019)
https://lists.oasis-open.org/archives/dita/201906/msg00028.html (Eberlein, 10 June 2019)
Additional e-mails ...
Scott: I am not sure about the latest proposal discussed but what I'm looking for is a way to semantically identify exemplary content in more places.
Kris: We really were waiting for you to return. I've heard offline that more people want to consider just allowing example to be available within section as well as in its current section-like element.
Scott: We definitely need to allow example at places above section, without the restriction that they occur only at the end.
Kris: I think that's a misunderstanding of the current content models. In the spec we have concept topics that intermingle examples and sections. That's currently permitted.
Scott: But if I have a para followed by an example within a list and want another example within a list I don't have the ability to mark content as being an example. I want to allow it at lower levels, not just at that higher section-block level.
Kris: One possibility would be making the current section element available at a block level within sections, similarly to table. I don't think that would address your wanting to have a semantic for section within a list item.
Scott: I don't want to have to use a section in order to have example in more locations. I need it at a lower level.
Dawn: What I do for clients right now is put an example attribute on note; that allows it in more places.
Kris: That's another possibility we raised -- adding another token to note that would be specific to example.
Scott: That might work OK. What I really like was having the example element. It's just more clear to authors when an element's available.
Kris: Robert did you have some thoughts?
Robert: I know several proposals have been made, and they have pros and cons. I don't know which one is the best. As a stage one level request this is just an identified problem.
Kris: Maybe we want to move this through to stage two, but we want to knock some of the possible technical problems out of the way before we do.
Robert: I agree.
Kris: I've previously felt example should be a high-level element.
Robert: If we get rid of the preconception of an example being like that, other things seem more reasonable. Anywhere div goes? That might be abused, but is that a reason to block it?
Eliot: The spec is clear that example is a kind of section. But it's a base element so it was never specialized from section, although it could easily be. But it's a titled element.
Robert: I don't think anyone wants a specialization of section.
Eliot: I'm wondering if it would make more sense for example to be a specialization of figure, which can occur in any block context.
Kris: But wouldn't that have an effect on the current role of example as a peer to section. I'm not sure we want to disrupt that.
Eliot: My email response to Scott's original email was to define a new element like examplediv. Problem is that wouldn't allow a title. Continuing in that vein you could define examplefig.
Robert: That would pretty severely constrict the content model as compared to example today. Figure is pretty limited compared to section/example. I've heard several things that could be done as a potential way to solve this.
Chris: Could we just make example part of basic-block? We could put it anywhere we want.
Robert: The only real reason to oppose that is if example is considered a high level titled thing. It requires a change in thinking about what the element is.
Chris: I think there's a pretty clear need for titled examples in places besides the top level.
Robert: If we just put it in that group we might end up having nested examples.
Kris: Unless we do something about it, it would allow infinite nested examples.
Robert: You can do that with many elements today, even titled ones. Probably have to think about it the way you do about figure today.
Kris: The only other viable option we've had is to add an example token to note. Scott maybe you want to think about these.
ACTION: Scott to compare options and think about which approach we want to take.
Dawn: Question about the 2nd option. If I have existing content followed by example and example becomes akin to fig does that make the topic invalid?
Robert: Only if we choose to make it so. That restriction today only applies in concept topics.
6b. Change specialization base of imagemap
https://lists.oasis-open.org/archives/dita/201907/msg00026.html (Lawson, 09 July 2019)
KJE: Lots of e-mail on list; I'm adding the useful ones
https://lists.oasis-open.org/archives/dita/201907/msg00030.html (Nitchie, 09 July 2019)
https://lists.oasis-open.org/archives/dita/201907/msg00034.html (Magliery, 09 July 2019)
https://lists.oasis-open.org/archives/dita/201907/msg00036.html (Kimber, 09 July 2019)
Zoe: My basis here is I'd like to have a title on it. I'd like to be able to use it like I use an image, but I'd like to have a title on it.
Robert: Would it make sense to put the title *in* the image rather than sticking the image in a titled figure?
Zoe: It might be a little weird because I think of an imagemap as a type of image. But that's just semantics; I can accept a little bit of weirdness.
Kris: This raises the question of whether you want to use existing figure processing to generate a list of imagemaps.
Robert: It's an oddity because imagemap is specialized from fig; most processors would suddenly include it in your figure list which you may or may not find weird.
Kris: My preference would be either adding it to base or specializing from div.
Eliot: I would object to adding it to base because it privileges a design which is not necessarily a good design.
Kris: Plus many many people do not use imagemap.
Eliot: Specializing it from div is the easier solution.
Robert: I'd like to think we would have done that from the first place if we had had div at the time.
Chris: Agreed. Imagemap is kind of an antipattern anyway. I'm all for not having it in the base.
Robert: I don't encounter imagemap often but I did encounter one last week.
Kris: I think I'm hearing a general leaning toward the option of respecializing of imagemap and area from div.
Chris: I'd be ok to leave area based on data.
Kris: Is it today?
Chris: Oh, no, it's figgroup.
Robert: The stuff inside is cross-refs.
Kris: Shall we make this proposal to change the specialization of imagemap and area to div and move this proposal to stage two?
Kris: Zoe do you want to champion this? I am willing to do so.
Zoe: I'd like to be involved.
Kris: I will be the champion for this.
ACTION: Robert set up a stage two card for this.
6c. Remove @lockmeta
https://lists.oasis-open.org/archives/dita/201907/msg00047.html (Eberlein, 11 July 2019)
https://lists.oasis-open.org/archives/dita/201907/msg00050.html (Anderson, 15 July 2019)
Kris: I just posted last week about this because I thought the spec was unclear. It says the lockmeta attribute enables the metadata in the map to override metadata at the topic level. I think this wasn't clear. Our 1.3 element reference topic gets ambiguous because of implying that navtitles are metadata.
Robert: For the last 10 years when people ask about this I politely change the conversation. That sort of summarizes my feelings. It was based on the idea of toolkit based processing where files are changing and you need to change those. We've gotten away from having that kind of processing definition in the spec. The driving force behind lockmeta was "I want to put some metadata in my map"; this was a way to say "ignore what's in the topic, I'm using this metadata only". I think no one really uses this attribute much, and this is a poor implementation of it.
Kris: Any thoughts, comments, questions?
Scott: Is there still a way to prevent the cascade? Because that's what lockmeta provides.
Robert: If it does that it would surprise me. As defined it's not related to that.
Kris: We have two options; we could just go ahead with a stage 2 proposal to remove it. Or we could ping folks on dita-users for examples of existing implementations. My tendency would be to go ahead with a proposal. It's poorly defined and doesn't fit without current understanding of maps and context.
Scott: Looking at the 1.3 spec it does affect how the metadata specified by the topicmeta element cascades. So that's saying you want to keep the specific metadata you've applied to a topic, you don't want it cascaded from the map, right?
Kris: I don't think so.
Scott: I can't think of times I've seen this used.
Robert: All we say in the spec about lockmeta is that it indicates whether the metadata information should be replaced by the metadata information in the referenced topic
Scott: Which would essentially prevent that override
Robert: I don't think it says anything about cascading, at least as we've defined cascading in the spec
Kris: I think it's entirely ambiguous by virtue of the phrasing overrides or augments. That's an apple or orange.
Scott: When you're saying metadata is supplemented I'd assume its cascading
Robert: We may be using cascading in different ways. The intent here is if I have lockmeta=yes use what I've said in the topicmeta element and ignore what it says in the topic. Which is a little bit weird. You can see in the 1.0 spec the attribute was declared but undefined. This processing was imagined around it but nothing implemented. In 1.1 we couldn't remove the attribute but we defined it based on this older idea.
Kris: We've got three folks on this call who are heavily involved with processing implementations. DITA OT, Titania, DITA for Publishers. Do any of those implementations use lockmeta?
Robert: We don't in the XSL anywhere, I will check the Java code.
Chris: Can't think off the top of my head. Would have done it a long time ago and moved on.
Eliot: In the abstract it makes sense that a map author would override data in a topic.
Robert: That's what you do by virtue of creating a map and putting in metadata. In this context I'm using this metadata. This attribute gets a lot more targeted, which is weird. It feels weird to have a processing attribute for processors that says ignore what I'm specifying in this referenced file.
Eliot: Thinking about the scope of requirements, to be able to ignore metadata from a topic is a legitimate requirement.
Robert: I think that's why we ended up with this attribute. But without a requirement the definition is poor.
Chris: In terms of design it's kind of inadequate.
Robert: The only place lockmeta is mentioned in the DITA OT is in our grammar files. No code anywhere.
Chris: Titania has one reference to it, and it's wrong.
Scott: If there's no actual implementations it's just going to confuse users.
Eliot: If OT doesn't use it, 95% of the DITA community could never have used it.
Kris: I hate for us to have things in the grammar files or the spec that are vague, ill-defined, and not understood.
Robert: And useless.
Kris: So either we remove this or we make it real. In absence of anyone who wants a new implementation of it, I suggest we move this to stage two and remove this attribute. Objections?
Bill: I'd be happy to be the champion for this with a little guidance
ACTION: Robert make a stage two card for it, Bill as owner.
7. DITA 2.0 stage two proposals
(none)
8. New item: PDF of approved DITA 2.0 proposals
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/65626/latest/DITA-2.0-proposals.pdf (Eberlein, 16 July 2019)
Kris: I built a PDF that aggregates our stage 2 proposals. It's currently 189 pages.
On one hand this will be essential as Zoe starts on the committee note about migration.
I also think many people outside the TC would like to see the approved proposals.
Publicizing this location to people will be helpful.
(Few comments of support.)
Kris: Btw this was generated with our new generic TC work product PDF transform. I encourage people to use this plugin. It uses styling identical to the spec and is a little easier to read than default styling from the toolkit.
9. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
Kris: Anybody have any updates about ETA for these proposals?
Robert: I have a couple more to add of my own but will be out next week.
Kris: I should do the same about the stage 3 for indexing. Will have mine out on the agenda next week.
Zoe: I have reviewer comments on my stage two proposal but it probably won't get touched until mid-August.
Chris: I'm trying to get to the specialization rehash but the day job keeps getting in the way. Give me a September deadline, I'll do what I can.
10. Continuing item: Proposed review of DITA 2.0 elements to LwDITA components
https://lists.oasis-open.org/archives/dita/201902/msg00042.html (Evia, 09 February 2019)
https://lists.oasis-open.org/archives/dita/201902/msg00047.html (Eberlein, 12 February 2019)
Kris: Robert and Alan and Carlos and I met, looked at reuse between 2.0 and LwDITA. One possibility fell by the wayside given current OT processing but one thing I did last week was move most of DITA 2.0 content for elements in LwDITA into reuse files that both LwDITA and 2.0 spec will use. As of now all of that content including attributes is marked up so it can be conditionally processed between the two specs, including work to handle the LwDITA SC's desire to use the word "component" instead of "element".
Grab the source from github from the 2.0 branch and you can see what we've done.
Carlos: Alan and I have a work session scheduled today to prototype topics reusing attributes because we've been wroking on reusing content.
Kris: I think the work I did sets up reuse of DITA attribute content for XDITA. I'll be interested to see how you envision coverage of attributes in HDITA or notations in MDITA.
Carlos: We're going to have to make some changes and I'll get back after Alan and I talk.
Closing announcements:
Dawn: We need more DITA Europe speaker proposals! We have already extended the deadline. Please get proposals to us ASAP.
12 noon ET close
-- Mr. Tom Magliery
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]