OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Groups - DITA TC Meeting Minutes 9 September 2014 uploaded

Submitter's message
Action Items:
1. re @scalefit on images: in the spec, Robert will add text 'up or down' within the phrase 'may be scaled to fit'
2. re element naming conventions wrt SVG vocabulary: Eliot and Robert will modify the code and the spec, respectively, to change svg_container to svg-container, and also to remove the dash '-' between the ditavalref ('dvr') prefix and it's various suffixes.

Minutes of the OASIS DITA TC
Tuesday, 9 September 2014
Recorded by N. Harrison
link to agenda for this meeting:

regrets: Chris Nitchie, Bob Thomas

Standing Business
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201409/msg00006.html (2 September, Nancy Harrison)
Proposed by Kris, seconded by Dick, approved by TC

Subcommittee Reports


1. DITA 1.3 progress
First spec review (Eberlein & Anderson)
kris; had call w/robt; committed to completion of key-based content by next week; if not, we'll do a targeted review of spec, subjectscheme, spec/constraints
Transformation utilities and DITA 1.3 grammar files (Kimber)
no update

2. Action items
a. Action items from 19 August 2014
Shells for L & T: Robert, Kris, Eliot, and John to meet when John is back from vacation; Kris is trying to schedule a call.
b. Action items from 26 August 2014:
- Don will draft a note on our decision to use the 'xml' prefix for our xmlmention domain, to be put into xmlmention topic.
- Kris and Robert will fix the arch/lang spec as suggested to include the correct information in spec about RNG-to-DTD-and-XSD generator.
- Nancy will review specialization and constraints topics, with the purpose of: a) suggesting placement for new topic or content chunk, b) reviewing for clarity, organization, technical accuracy. This is in regard to content re limitations of XSD shells and constraints.
c. Action items from 2 September:
Eliot to rename svg_container to svg-container
Kris will modify svg-container topic
Robert will modify spec topics re "to-navigation" value for @chunk
(will get this done this week)
Stan to assess Front Page wiki for possible clean-up
no update
Kris will generate new versions of the 1.3 spec.
done - she just generated a new chm

3. New item: Question about @scalefit on images
https://lists.oasis-open.org/archives/dita/201409/msg00005.html (Anderson, 8 September
Kris; question is; should this @ be used only to scale down, or to scale either up or down.
Don; any reason to prohibit scaling up?
Eliot; normally not what you want, but not really any reason not to allow.
Kris; any use cases for that?
Tom; kind of imaginary; freezing output that's being used for a slide show? But I don't feel too strongly about this.
Eliot; is this from 1.1 or 1.2?
Kris; 1.2
Eliot; XSLFO has a 'scale-down-to-fit as well as scale-[up-]to-fit
Kris; the general use case seems to be scaling down.
Dick; I'd argue for scaling only down. Another case might be scaling everything only to one size.
Kris; who championed scalefit for 1.2? what was the rationale? Also, what coverage do we have in the spec for this? [Robert and Jarno would prefer to only have scale down.]
Eliot; since XSLFO uses scale-to-fit, scale-down-to-fit, scale-up-to-fit, if we change it, it should be to align with XSLFO.
Kris; does the spec permit % on @width?
Eliot; no, but all scaling @'s reuquire a % as parameter. If we want those, we'd need to add these keywords.
Kris; to clarify, we're not proposing changes to 1.3 grammar. We're simply proposing clarification of description.
Eliot; I don't think scale-up is allowed by text of 1.2 spec.
Don; this comes from DocBook; allows 100%, which might imply osme upscaling. I'd be disinclined to prohibit upscaling.
Kris; does @width allow percentages. I didn't think so; I think they're only absolute measures.
Eliot; that's so, only @scale is a perscentage. If either @width/@height is specified, scale/scalefit is ignored.
Don; i'd just rather not constrain usage.
Nancy; I'm with Don on this.
Kris; someone should look at the spec language
Eliot; the spec language is clear; it simply says it scales to fit.
Don; maybe we could add the implications
Kris; the fact that it came to the TC means that it's not crystal clear; if we can craft a sentence that clarifies this, that would be good.
[discussion; Eliot very strongly opposes changing spec language to not reflect actual code, using xslfo object.]
Michael; in the DocBook spec/user guide, there are a whole bunch of examples of scaling to fit upwards; if we borrowed this from them, that's what it was.
Kris; So we have 2 potential actions;
1. get some sample additional spec language and see if it can be clarified. (Don volunteered.)
2. put this on list of items for 2.0. (Eliot will give this some thought.)
ActionItem: in the spec, Robert wil add 'up or down' after 'may be scaled' and before 'to fit'.

4. Continued item: Plans for dita.xml.org
Notes from call on 27 August 2014
Michael's original post to list / OASIS requirements
https://lists.oasis-open.org/archives/dita/201408/msg00036.html (19 August 2014)
TC minutes from 19 August
Kris; see the minutes of the Aug 27th call. The goals & requirements decided on at that call will be content of RFP for vendors.
Don; do we need to ask if OASIS has its own goals/requirements for the site?
Kris; we need to be very careful about what we ask vendors to support.
Don; especially since we're requiring native DITA processing...
[recap of mail content]
Don; Carol Dwyer of OASIS agreed with comments.
Kris; who can work with this?
Tom; will sign on as a reviewer
Kris; looking for volunteers for coordinating this work - will keep asking.

5. Continued item: Element naming conventions (svg_container?)
https://lists.oasis-open.org/archives/dita/201409/msg00000.html (Frederik Geers, 2 September 2014)
[Left on agenda for when Robert is present; general policies about element naming conventions affect the DITAVALref domain.
[SVG renaming has been done]
Robert; my initial reaction is a shrug; if we want to remove the token and leave it camelcase it's fine with me. If nobody cares, leave it alone.
Eliot; I'd prefer it be one or the other. but not both.
Kris; there also could be a lowercase suffix or prefix.
Robert; my default would be to follow L&T model; there are 2 lowercase elements, and 4 with dvr-'camelcase'. So I'd rather just remove the '-', leave the camelcase.
Robert; the keyscope prefix should be there, just rename 'keyname'
ActionItem: Eliot will fix the code to remove dash after keyname and make changes to grammar files (remove '-' and use camelcase
ActionItem: Robert will fix spec topics same way

closed at 11:56

-- Nancy Harrison
Document Name: DITA TC Meeting Minutes 9 September 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-09-15 21:27:07

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]