dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 3 March 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 9 Mar 2015 16:23:11 -0700 (PDT)
Submitter's message
ActionItems:
1. Nancy; will update meeting scheduling tool to set up DITA/S1000D meeting
2. Eliot will move non-normative content from doctypes and rng directories to a different location.
3. Don will do follow-up on dita.xml.org call
4. Robert will make changes wrt "default values for @domains within specializations"
5. Robert will make changes to spec related to "Another somewhat technical DTD issue - nesting topics"
=================================================
Minutes of the OASIS DITA TC
Tuesday, 3 March 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: Chris Nitchie
Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201502/msg00058.html (17 February 2015, Nancy Harrison)
Proposed by Kris, seconded by Dick, approved by TC
Subcommittee Reports
none
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
ActionItem: Nancy; will re-visit tools and go forward with that
- Action items from 10 February 2015
Robert: Draft new normative languages about keys and subjectScheme
Robert; not quite finished; hope to get to them this week
- Action items from 17 February 2015
Eliot: Move all non-normative content from doctypes and rng directories
Eliot; not yet done, will work on this this week; don't yet have a place to relocate all of the code.
Kris; even if we just put them in a different location in SVN, that would help.
ActionItem: Eliot will move non-normative content from doctypes and rng directories to a different location.
Robert: Will talk to Jarno about 'combining metadata from a key reference element and a key-defining element'; example needed
Robert: Rewrite key definition precedence text (with input from Kris and Chris) and accommodate Eliot's concern
2. Update on dita.xml.org initiative
Don; we had meeting last Fri. w/ all major vendors on the call; we went thru the model we'd like to sustain, including requirements for providing service on site. OASIS will continue what they have been doing, so the vendor will mostly need to provide software. We had discussions on role of content; workers themselves will be tiger team; need to discuss sharing of source. It looks like we will need at least one more meeting on 'what kind of content'; ownership roles; services on that content; and what back-end functionality do we need (still no consensus on that).
Kris; questions?
Chris; this is at an interesting phase, where requirements will be problematic, so that's what we have to work on.
Kris; yeah, the call showed that there isn't as much consensus on requirements, between TC and Adoption TC, as expected.
Don; I'm ready to do follow-up on the call; I think we can do some email and get closer on requirements.
ActionItem: Don will do follow-up on dita.xml.org call
3. Targeted reviews progress: January - February 2015
- Schedule for targeted reviews:
Progress on branch filtering:
Robert; branch filtering review is closed; we just have to go thru the comments; also, conditional processing reviews are now archived
Processing etc.: All voting members are asked to participate
TBD: Direct addressing; DITA linking; Keys; Keys revisited
Configuration, specialization, and constraints: Volunteers requested
Jan 06-19: Constraints (19 pages) -- CLOSED; editorial work on-going; review and comments archived
4. Status of rework of "Configuration, specialization, and constraints" (Anderson and Eberlein)
Robert; I've been working on this over last couple of weeks; has been adding draft-comments in preparation for work to come. Also, doing a reorg of the coding examples, and file naming sections; trying to consolidate coding practices for everything together, so we'll have all normative info, then all DTD, then RNG, then XSD, info. I've checked this in; got some feedback from Kris on coding. Also, my review highlighted how much these sections have grown willy-nilly over the years. So we're coming back to an organization closer to DITA 1.0; and that's what we'll be needing input on. I think we'll be looking for help.
Kris; We think it's vital to be clear in the concept material about vital areas like specialization, generalization, constraints, vocabulary modules, etc, and have that separate rfrom coding practices. Over time, things had been added in such a way that there was no coherent flow.
Kris; if there are people on TC who can work with us on org. of this, or are willing to help us as we try to unnest current material, that would be great. Volunteers? We need folks who actively develop doc shells, specializations, constraints. Later, we'll need other folks.
[Nancy, Bob, Eliot, EricS volunteered]
5. New item: Default values for @domains within specializations
https://lists.oasis-open.org/archives/dita/201502/msg00052.html (Anderson, 23 February 2015)
Robert: the spec currently includes a section from DITA 1.2 spec stating that "modules must define the included-domains parameter entity. This is usually empty but in some cases must have a meaningful default." But doing this is always meaningless, because every specialization, topic or map, structural or domain, builds on either the core topic module or the core map module, and both of those modules define the included-domains entity. When entity is defined in both a specialized entity and a core module, the core definition wins. So the empty definition always wins, and the one you have to put in is always meaninglass. These domains were included in most of our modules; none are in current 1.3 modules.
Kris; any objection to removing this normative statement?
Chris; It's not completely useless; it allows a structural module to state its conformance with core modules.
Robert; yes, but why does it matter?
Chris; it's there for the people, not for the process, like having a rule/best practice to include a core module if you have a structural module.
Robert; I also have a tangent to bring up...
Kris; any objections to Rpbert broinging up a tangent?? [while keeping open issue of including a comment about best practices]
[no objections.]
Robert; we agreed to remove all normative comment requirements, except in RNG topics 'you must comment your domain module to ..." The domain module has a value that's required for the shell. Do we want to say "If you have a @domains token that others need to know about outside this file, you must include it."?
Eliot; if you don't put a comment in an RNG file, and you have a domain module that's required, how else do you know about it? XSD and RNG don't have text entities like DTDs, so a comment about included domains is necessary. We could say "you should really document this in your module."
Robert; it's not a MUST; if you don't put it in the doc shell, it may be that nothing bad will happen. If a document uses a shell that used this domain, and is exchanging content with another document that uses a shell that also uses this domain name, you might have trouble. But generally nothing will break.
Eliot; conformance responsibility falls on the @domains atribute, we can't make it a MUST, but maybe a SHOULD?
Robert; I don't think we can even make it a SHOULD, a SHOULD is only allowed to be used if there's a likelihood of something breaking.
Eliot; it depends on how you define 'break'
Robert; 'break' means a user or processor breakdown
Kris; I'm looking at def from RFC. ""
Eliot; In this case, people will have a hard time knowing the value of a domains module if you don't document it.
Kris; we could use a lower-case should, just not a normative SHOULD.
Robert; we could do that. So this can't be a normative MUST, but we do need it in there, as a normative SHOULD or a 'should'.
Kris; we're moving to a model of using normative language sparingly, where it's tied to processing or implementation implications.
[resolution; Robert will make those changes]
ActionItem: Robert will make changes wrt "default values for @domains within specializations"
6. New item: Another somewhat technical DTD issue - nesting topics
https://lists.oasis-open.org/archives/dita/201502/msg00055.html (Anderson, 23 February 2015)
[see email]
Robert; we have conflicting language in the spec, wrt an edge case. Now, you can create a specialized topic, with specialized subtopics. In the spec, structural specialization is confined to one module; you can have a concept module, with specialized concept modules as sub-topics. but in the coding requirements. the only way we let you mark it up is to have a parameter entity to control sub-topics. The spec says 'you must control nesting like this', but other language says 'you can do it this other way', we have to change language to allow both.
Kris; so we need to change, where it says "a topic type module MUST define...." to "SHOULD"?
Robert; Maybe not even that; just say it's better to do this way. But actually, we probably should use the normative SHOULD; it still represents the usual case. so SHOULD is probably appropriate.
Kris; go ahead with the change.
ActionItem: Robert will make changes to spec related to "Another somewhat technical DTD issue - nesting topics"
7. New item: Intent or implications of topicrefs in relcolspec
https://lists.oasis-open.org/archives/dita/201502/msg00042.html (Kimber, 18 February 2015)
Eberlein: This 1.2 feature was championed by Erik Hennum. Here is a link to the original proposal:
https://www.oasis-open.org/committees/download.php/24839/IssueReltableHeader12048.html
Eliot; the language in the 1.2 spec simply says " ", but it doesn't specify the nature of the relationship or processing implications, and it has no examples of a topicref to a topic. It doesn't say what it means to have multiple topicrefs in a relcolspec.
Don; it may have seemed like a good idea at the time, but no one uses it.
Kris; it would be interesting to see if anyone uses this...
Robert; there were a couple of reasons within IBM why that was pushed; but we're not using it now in IBM.
Kris; so, it's not in use in IBM. Eliot, is it your recommendation as this is something to consider when we rework reltables in DITA 2.0
Eliot; yes.
meeting closed at 11:59
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]