dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 10 March 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Wed, 11 Mar 2015 12:03:17 -0700 (PDT)
Submitter's message
ActionItems:
1. Kris and Robert will meet on a call and review branch filtering comments
2. All TC members to review linking material
=================================================
Minutes of the OASIS DITA TC
Tuesday, 10 March 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: none
Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201503/msg00014.html (3 March 2015, Nancy Harrison)
Proposed by Kris, seconded by Bob, approved by TC
Subcommittee Reports
Lightweight DITA (LD) Subcommittee
Michael; we've got a good group of folks; attendance has been a bit slow, in part because there's such a wide time zone distribution (i.e. ET, CT, PT, Europe, & China). The group is looking at what topic elements will be needed, relative to the various use cases for different industries (e.g. L&T, machine industry, software, etc). We're also mapping a starter set of elements to equivalents in other formats, e.g. HTML5, Markdown. Jarno has added capabilities to DITA-OT so it can do Markdown->LD and LD->Markdown. We're looking for ways to preserve specialization semantics in Markdown. We're looking at Don's 'any-to-DITA' tool. also a Jason-LD mapping. The mapping and rapid prototyping are going in parallel with development of LD design; we're already at the point where we have folks eager to prototype various doctypes.
Kris; just a note; I've been trying to announce when we get new TC members, and a number have joined because of LD.
Announcements
none
Business
========
1. Action items
- Action items from 2 December 2014:
Eliot: Move RNG-to-DTD-XSD generator code to GitHub (on hold)
- Action items from 13 January 2015
Nancy: Schedule meeting with Jean-Jacques Thomasson
Nancy; will do that today
- Action items from 10 February 2015
Robert: Draft new normative languages about keys, subjectScheme [not yet done]
- Action items from 17 February 2015
Eliot: Move all non-normative content from doctypes and rng directories [done]
Robert: Will talk to Jarno about 'combining metadata from a key reference element and a key-defining element'; example needed [not yet done]
Robert: Rewrite key definition precedence text (with input from Kris and Chris) and accommodate Eliot's concern [not yet done]
- Action items from 3 March 2015
Robert: Make changes wrt "default values for @domains within specializations" [done]
Robert: Make changes to spec related to "Another somewhat technical DTD issue - nesting topics" [done]
Don: Follow-up on dita.xml.org call
Don; Chris has told us Oberon will be pulling the HARP proposal off the table. Also, in light of disagreement on expectations between the DITA TC and Adoption TC, we need one more meeting; I'll write up a new proposal of required features and get agreement; will do that this week.
Kris; please do that and have the next call with core and Adoption TC members done this week.
2. Targeted reviews progress: January - April 2015
Schedule for targeted reviews:
- Progress on branch filtering: X
ActionItem: Kris and Robert will meet on a call and review branch filtering comments
- Processing etc.: All voting members are asked to participate
March 10-16: Linking Linking (10 pages)
Kris; the linking section is not as ready as others; we have a lot of questions in draft-comments.
Robert; basically, there are 3 issues with the content:
- It contains material that we think might be better suited to a best practices white paper.
- It uses terminology that is not formally defined.
- It introduces terminology that is used only in these topics.
We're not sure if a lot of it is really necessary in the spec; we were trying to figure out where this info should be placed and how it should be organized, and it led us to wonder about the material itself.
- Kris; our concerns are whether this is content that should be in the spec. Most of it was added late in DITA 1.2, the rest came in during 1.3 as part of cross-x-deliverable linking. We've looked thru the content and posed questions; we need the TC to look at this and see if it belongs in the spec, especially wrt some terms that aren't really defined, and others that are used only in this topic and not in the rest of the spec.
- Eliot; as the author of this content, my perspective is that you can use DITA as the most sopisticated hyperlinking system now in use; that's a really important aspect of DITA, but also a very challenging aspect of DITA; complicated and abstract. My goal in writing these topics was to describe DITA's hypertext nature, in terms used in the hyperlinking field. I tried to have those terms defined in DITA 1.2, but got serious pushback, so I put them, with definitions, in my description. I agree with assessment that there's some redundant content, which could be pulled out or collapsed. but I think the content is useful. I wanted to help people keep from conflating linking and addressing. linking is independent of the form of addressing.
- Kris; at this point, Robert and I want all TC members to review this content and respond in DITAWeb.
- Eliot; I was trying to help people not make the same mistakes about DITA that's made about HTML.
- Don; sounds a lot like a drmacro rant to me; would drmacro be a good chanel for publishing this?
- Eliot; much of it is also in my book.
- Don; but the spec isn't the place for a polemic
- Eliot; but having a section that distinguishes linking from addressing.helps to understand DITA linking architecture. I found it necessary to write about links. I
would very much like terms like 'map tree', 'navigation tree' defined in spec.
- Kris; any other comments?
- Bob; it's helpful to understand context with with it was written; will help my review
- Stan; ditto
- Kris; Thanks, Eliot, for providing the context; we want TC members to do a really careful read of this content. Think about: is this clear? should it be in the spec? in this part of it? in another part of it? Robert and I don't have good answers, we need help from rest of TC.
- Robert; we've fixed some typos, and syntax, so most of the comments are questions, except for some places where wording isn't clear.
[resolution; TC members will review]
3. Review #2 comments:
- Continued item: Subject scheme (on hold until after targeted review of subject scheme material)
- Continued item: Combining metadata from a key reference element and a key-defining element (on hold awaiting feedback from Jarno)
https://lists.oasis-open.org/archives/dita/201412/msg00018.html (Eberlein, 7 December 2014)
Robert; I got feedback from Jarno; it's part of the rework I did in addressing March 3 action items; we can take this off agenda; we'd said metadata cascades from keyrefs to key definitions; problem is we don't say which takes ancestor role; keyref or key definition; I think everyone will agree on resolution
4. New item: Navigation tree terminology conundrum
https://lists.oasis-open.org/archives/dita/201410/msg00196.html (Kimber, 28 October 2014)
- Eliot; this goes with the linking section discussion above. We need to make distinctions between 3 diff classes of topicrefs; reltable, resource-only, normal (not in reltables), but nowehere in the spec is the difference formally defined. Now, with branch filtering and key scopes, we need to come up with a term that means a normal topicref not in reltables.
- Michael; there are attrs, @toc, @processing-role. if you set @toc="yes" in a reltable, would it show up?
- Robert; it would show up, though I don't know why someone would do it.
- Michael; so reltable, resource-only, normal not in reltable
- Bob; those are structural
- Kris; or they can be a subjectdefinition
- Eliot; all subjectscheme ones are @resource-only by default
- Michael; but someone could single-source a glossary in a taxonomy; we're talking about classifyig topicrefs by natural behavior, but using that we get a combinatorial result. So maybe defining them based on these clusters may be confusing.
- Eliot; so 99% of users use them in 1 way - to produce TOCs. There are places in the spec that talk about implications of navigation and TOCs. but it's hard to talk about a 'normal' case if we don't have terminology.
- Don; we're talking here about possible renditions of what can be done. Processing controls will create a particular rendition, but implementors can devise any role/rendition. Maybe we can use 'view'? We want to give freedom in our language as to what can be done with data models.
- Eliot; I like the connection between view and data model. There's a separation between data and view/rendition. Anytime you introduce abstraction, it makes things more difficult.
- Don; it's our opportunity to use correct language.
- Kris; as spec editor and spec user, I'm very concerned when we talk about introducing new language to the spec. My response is that this might be over-specifying, or making the spec too complex. Do we need an additional level of complexity in our terminology?
- Michael; can you give me example of what you mean, that isn't topicref toc="yes"?
- Eliot; topicrefs that establish a hierarchy.
- Michael; but you can have hierarchy within reltables.
- Eliot; But we treat that as a flat list of links
- Kris; When did we decide that?
- Robert; We've discussed mapref in a reltable cell
- Eliot; And that gets you the map hierarchy?
- Robert; I understood that we leave this alone; we didn't decide that it had no meaning
- Eliot; We decided treating it as flat list wasn't mandated. so within a reltable you can still have hierarchy. so a number of behaviors are unspecified.
- Michael; But I don't see them as unspecified. If something is in a reltable, toc="no" by default, but linking is on by default, so links should be created in the hierarchy.
- Eliot; Perhaps better language is to say any hierarchy of topicrefs can be treated as a navigation structure.
- Michael; They also relate to other topicrefs within a cel.
- Eliot; The spec language says 'there is no specific connection between topicrefs established by the cell.'
- Robert; Unless you assign a collection type to the relcell.
- Robert; Where is the convoluted language outside of the linking section itself?
- Eliot; In context of branch filtering, when you add a branch...
- Robert; That's not my impression. Part of my question about this section is that it feels like most of processing expectations are covered elsewhere.
- Michael; We've got a cluster of @s around DITA. We could use a better set, e.g. @toc, @print. I wish that area was cleaner. But we basically say 'processing is attr-based, therefore it participates in certain behaviors.' We could have a summary topic that says 'these attributes imply these behaviors'. We should keep the spec focused on technical details that will matter to implementors.
- Kris; let's continue this on the list and next week.
meeting closed at 12:00
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]