| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 18 March 2014 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 21 Mar 2014 16:58:38 -0700 (PDT)
[action items already sent out]
Minutes of the OASIS DITA TC
Tuesday, 18 March 2014
Recorded by N. Harrison
link to agenda for this meeting:
regrets: Stan Doherty (attended late)
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201403/msg00101.html (11 March, Nancy Harrison)
Proposed by Kris, seconded by Deb, approved by TC
1. DITA 1.3 progress
- RelaxNG-to-DTD and RelaxNG-to-XSD transformations (Kimber)
Eliot; finished work as planned. everything has passed validation tests, including MathML & SVG.
- DITA 1.3 grammar files (Kimber)
Eliot: DTDs and RNGs are done XSDs are lagging.
Kris; how can we make RNGs & DTDs available?
Eliot; currently, they're in SVN repository; mimics OT toolkit architecture/structure. I've been talking to Jarno about packaging them as a plugin for DITA OT 2.0 toolkit.
Kris; for our purposes, we don't need them packaged that way. It's better if your could upload a ZIP file to KAVI, so everyone can use them. When could that be?
Eliot; I've set myself a deadline; next TC meeting.
Kris; I'll hold you to that.
Don. my understanding is that Jarno has already been doing DITA 1.3 support in the DITA OT.
Kris; It's one thing for OASIS files to be in the DITA OT, but we have to have an OASIS-hosted version of what we expect to deliver to OASIS, for anyone who doesn't want DITA-OT. And it's important for packaging to not impact the delivery schedule.
- Redesign of "Contains and Contains by" (Anderson)
- First spec review (Eberlein)
(see below under item #2)
2. First spec review: 2-16 March 2014 (Eberlein, Anderson)
- Overview of participation
Kris gave an overview: review #1 is now complete.
- Goals were achieved, and what's left undone:
- Lacking only owner review:
Anderson: 13008, 13056, 13059, 13059a
Learning & Training SC: 13106
- Review incomplete: 13001, 13060, 13061, 13121
- Problem areas
Keys and key scopes; we always know this would need major review.
- Plan for completion:
Action Item: By next week, Kris and Robert will evaluate results and make plans for next review.
3. New item: DITA 1.3 review process: Lessons learned
- What worked well?
Eliot; I thought it went really well. Thanks to Kris for setting up the DITAWeb tool with revisions organized by proposal.
[general agreement that Kris's preparations had lot to do with review success.
BobT; can't really see it getting much simpler than that.
Robert; this was more successful than any review ever done in DITA 1.2.
Eliot; the way we did the 3-stage preliminary reviews made it work much better; we didn't have to completely reword proposals for this review, so we could focus on small but important items.
Kris; ease was also driven by the fact that we used a subjectscheme to organize the revision values, and DITAWeb built a widget to enable using that easily. kudos to Mekon!
- What didn't work well work?
- Are there things that we need to improve?
4. New item: Errors in learning and training DTD / spec modules
Robert gave overview; this is really an error in way that L&T hotspot map was defined in the spec; when I compare it to other elements, I think it was a copy/paste error. It should be fixed to @class in spec; should be treated as errata in 1.2; for 1.3, we just need to fix it, but don't need errata.
Kris; any objection to our treating it as errata in 1.2, and fixing it in 1.3?
Robert; same thing came up in other elements in L&T; it would be good if someone from L&T SC could take a look.
Kris; Will the TC accept Robert's suggestion?
Eliot; I want to make sure we haven't done something incorrect w/ the hotspot maps; I want to doublecheck to make sure it's correct; 'hotspot' ddepends on base imagemap
1. log this as 1.2 errata in Trello
2. Eliot; check 1.3 work to make sure that specialization bases are correct.
5. New item: Question about default for @format when linking to file.htm
Robert; is the analysis correct? Does it rise to level of SHOULD, or MUST? I think it should be a SHOULD, not a MUST. It might otherwise be a backwards compatability issue, and could be a problem. It could cause some inconsistencies. SHOULD is still pretty strong.
Chris; we're only talking about where @format is not explicitly set; where it is set, nothing will change. It seemed reasonable to treat 'htm' as equivalent to 'html'; i voted 'MUST' but it's not a strong vote, it's OK if it's 'SHOULD'
Robert; very likely this is an edge case...
BobT; I'm wishy-washy
Robert; since we're definitely wishywashy, we should go with 'SHOULD'
Kris; I agree, we should go with 'SHOULD'
Kris; does that give you abiity to resolve review comments here?
Kris; everyone agree that applications should treat @format="htm" and ="html" as equivalent?
[general agreement from TC]
Action Item; Robert will resolve issue as described in email and this discussion.
6. New item: Question about what it means when @format conflicts with actual format
Robert; I kind of agree with Chris's point, but
Chris; There may be cases where it's ambiguous; there may be cases where @format is similar enough to make it difficult to tell, but I think it should be treated as an error where a file extension is obviously different from the specified @format.
Robert; processors shouldn't be forced to open the file to check.
Chris; they should have to issue an error.
Robert; so if a processor detects that it doesn't match, should it issue an error?
Chris; it is an error, and processors SHOULD report it
Robert; if a processor detects a mismatch, it is an error, it SHOULD be reported as an error, and a processor MAY recover gracefully.
Kris; agreement with above statement?
[general TC agreement]
Action Item: update spec to reflect above; i.e. if a processor detects a mismatch between a file extension and a specified @format, it is an error, it SHOULD be reported as an error, and a processor MAY recover gracefully.
7. New item: Collection of questions (7a - 7g) about branch filtering
Robert; this collection of items came from review comments.
a. the issue is that 'ditavalref' can affect keys within a map, and ditavalref itself has keyref, so that can go into a 'loopy' scenario,
- Suggestion is to remove keyref/conkeyref from ditavalref and its nested children.
Kris; TC consensus? we want branch filtering to be actually implemented by processors
[consensus by TC]
Resolution; remove keyref/conkeyref from ditavalref and its nested children.
b. What does it mean when you use a 'ditavalref' element that does not
reference a set of DITAVAL conditions?
b1. If the branch only has one 'ditavalref'
- no filtering will take place
- are child elements still used to rename files / keys?
- the answer is 'yes'
b2. If the branch has multiple 'ditavalref' elements
- does this result in one unfiltered copy of the branch?
- the answer is 'yes'; you get multiple sets, but an unfiltered set ends up in the output.
- you get an instance of the branch that doesn't include filtering.
c. If nesting 'ditavalref' inside a branch that already uses 'ditavalref',
in what order are suffixes / prefixes added? (see agenda for example of this, in which the initial 'ditavalref' causes every file name to add "-mac" to the end; the second one adds a suffix of "-novice").
Suggestion: outer ones on the outside, inner ones further in (suggested by Chris), doesn't leave this up to the implementation.
d. Comment that @lockmeta seems meaningless on 'ditavalmeta' inside
'ditavalref'. Robert agrees and would suggest removing it.
Suggestion: remove @lockmeta from 'ditavalref'.
e. For the 'dvr-resourcePrefix' and 'dvr-resourceSuffix' elements: these
result in renamed documents, filtered with specific conditions - but what
about documents we cannot filter? Specifically, does renaming affect
external documents, peer documents, or local non-DITA documents?
Chris; I suggest that we not rename "peer" or "external" resources but we do rename "local" resources.
Robert; I agree.
[Eliot & Robert gave a use case for renaming local resources...]
Chris; whatever the effect of renaming is, it should match the effect of "copy-to" on map.
Kris; what should the spec say about copy-to? Should we take it to the list, so we can then bring it back to the TC next week?
Resolution; we will bring this to the list and go back to it next week.
f. For those same elements ('dvr-resourcePrefix' and 'dvr-resourceSuffix'): can you include directory information? (see agenda for examples of this - are they valid?)
Consensus is that the answer is 'yes.'
Robert; the thought is to keep these in line with copy-to, so a dirname would be legal; not so sure about a full dir path; my assumption was that it's not allowed, but not forbidden in the spec.
Kris; do we want to forbid it in the spec?
Eliot; should we poll the community to see if anyone's actually doing that?
Chris; let's not assume a paradigm of creating a self-contained piece of documentation; i'm in favor of staying silent on this; if it's not prohibited now, it's not specifically prohibited; we should not mention it. If someday it's becomes a problem, we can address it.
Robert; it has led to problems when we stay silent, so I'm inclined to say something. We could say that 'it's not forbidden, but not supported.'
Kris; we'll roll e, f, and g (below) together for discussion on the list and come back to them next week.
g. If using @copy-to in a branch with resource-prefix, which is applied
first - the @copy-to value or the renaming of the original file? Robert thinks it must be the copy-to - otherwise for all copies of that branch, you would rename the filtered copy, then copy-to takes you back to single value. Another way of saying this could be - the resourcePrefix value applies to both the original href and to the copy-to value.
meeting closed at 11:59
-- Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]