Groups - DITA TC Meeting Minutes 18 March 2014 uploaded

Submitter's message

        ======================================================

[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:	

	https://wiki.oasis-open.org/dita/PreviousAgendas

regrets:   Stan Doherty (attended late) 

Standing Business

=================

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

Subcommittee Reports

	none

Announcements

	none

Business

========

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)

(no change)

   - First spec review (Eberlein)

(see below under item #2)

2. First spec review: 2-16 March 2014 (Eberlein, Anderson)

   - Overview of participation

     https://lists.oasis-open.org/archives/dita/201403/msg00163.html  

Kris gave an overview: review #1 is now complete.

   - Goals were achieved, and what's left undone:

       https://wiki.oasis-open.org/dita/List%20of%20Reviewers#Listofproposalsandreviewers

   - Lacking only owner review:

         Anderson: 13008, 13056, 13059, 13059a

         Kimber: 13041

         Learning & Training SC: 13106 

   - Review incomplete: 13001, 13060, 13061, 13121 

   - Problem areas

        Keys and key scopes; we always know this would need major review.

        Branch filtering 

   - 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

    https://lists.oasis-open.org/archives/dita/201402/msg00228.html  

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

Action Items: 

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

    https://lists.oasis-open.org/archives/dita/201403/msg00122.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00148.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00150.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00155.html 

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?

Robert; yes

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

    https://lists.oasis-open.org/archives/dita/201403/msg00124.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00149.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00152.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00153.html  

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

    https://lists.oasis-open.org/archives/dita/201403/msg00154.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00156.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00157.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00158.html 

    https://lists.oasis-open.org/archives/dita/201403/msg00159.html  

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
        
    

    
        Document Name: DITA TC Meeting Minutes 18 March 2014

        
        No description provided.        

        Download Latest Revision

        Public Download Link
        
        Submitter: Nancy Harrison

                Group: OASIS Darwin Information Typing Architecture (DITA) TC

        Folder: Meeting Notes

        Date submitted: 2014-03-21 16:58:27