| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 30 April 2013 uploaded
- From: Nancy Harrison<firstname.lastname@example.org>
- To: email@example.com
- Date: Mon, 6 May 2013 22:38:19 -0700 (PDT)
Minutes of the OASIS DITA TC
Tuesday, 30 April 2013
Recorded by N. Harrison
regrets: Robert Anderson; Deb Bissantz; Dick Hamilton; Michael Priestley
Minutes from last meetings:
https://lists.oasis-open.org/archives/dita/201304/msg00073.html (23 April, Harrison)
Proposed by Kris, seconded by Adrian, approved by TC
(DITA Adoption TC beginning of May)
Scoped key space construction, rough POC on GitHub; details at https://lists.oasis-open.org/archives/dita/201304/msg00062.html (Nitchie)
1. DITA 1.3 progress
Progress between April 8-21, 2013: https://lists.oasis-open.org/archives/dita/201304/msg00075.html
Update on deadlines: http://chris.nitchie.com/trellotrack/#511a73d76ee890a51c0007ed
Trello Board: https://trello.com/b/gPKH0OcF
Kris noted that there has been no movement between stages, but there are 2 new proposals from Eliot; also, we'll vote on ChrisN's #13004 today. Some other proposals need to be updated; owners will update on Trello. Also, there are a number of proposals without deadlines; we need to have owners put them in so we can start being a bit more proactive.
Also, trying to set up a webex Eliot and MichaelP's presentations from DITA/NA
Action items: for any proposal owners who need to add or update deadlines for their proposals in Trello, please do so.
2. DITA 1.3 proposals, stage 2: http://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage2
Ready for discussion on May 7; please read before then:
13010: Sort as (Kimber)
https://lists.oasis-open.org/archives/dita/201304/msg00066.html (DITA, uploaded 27 April)
https://lists.oasis-open.org/archives/dita/201304/msg00067.html (HTML, uploaded 27 April)
13041: Cross-deliverable linking (Kimber)
https://lists.oasis-open.org/archives/dita/201304/msg00071.html (DITA, uploaded 28 April)
https://lists.oasis-open.org/archives/dita/201304/msg00072.html (HTML, uploaded 28 April)
https://lists.oasis-open.org/archives/dita/201304/msg00070.html (PDF, uploaded 28 April)
Ready for vote: Voting options are "Yes," "No," "No objections," "I don't understand the proposal," and "I have reservations"
13004: Scoped keys (Nitchie)
https://lists.oasis-open.org/archives/dita/201304/msg00060.html (HTML, updated 23 April)
https://lists.oasis-open.org/archives/dita/201304/msg00059.html (DITA, updated 23 April)
Results: passed with 8 'yeas' and 5 'no objections'
yes: Stan Doherty, Kris Eberlein, Nancy Harrison, Tom Magliery, Chris Nitchie, David Helfinstine, Eliot Kimber, Thile Buchholz
no obj.: Adrian Warman, Michael Boses, Don Day, Mark Myers, Scott Hudson
3. DITA 1.3 proposals, stage 3: https://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage3
Ready to assign reviewers
Ready for vote: Voting options are "Yes," "No," and "Abstain"
4. NEW ITEM: Scoped DITAVAL files?
https://lists.oasis-open.org/archives/dita/201304/msg00063.html (Noz Urbina, 24 April)
Kris gave an overview, based on Noz Urbina's mail (above), and asked if we had anything in our proposals that covers the issue.
Eliot noted that RobertA and MichaelP are working on such proposals.
ChrisN said he hadn't seen anything in the Trello list, but thought the TC had discussed this.
Kris thought so as well.
Eliot wanted to know how one associates a scope with a ditaval, providing hierarchies of condition?
Kris thinks this may be implicit in some of RobertA/MichaelP's proposals, Resolution: discussion to continue on 7 May, when the relevant parties are hopefully on the call.
5. NEW ITEM: MathML proposal for 1.3: Early prototype questions
https://lists.oasis-open.org/archives/dita/201304/msg00034.html (Anderson, 10 April)
https://lists.oasis-open.org/archives/dita/201304/msg00035.html (Kimber, 10 April)
https://lists.oasis-open.org/archives/dita/201304/msg00036.html (Nitchie, 10 April)
https://lists.oasis-open.org/archives/dita/201304/msg00043.html (Swope, 11 April)
In Robert's absence, Simcha Gralla gave an overview. Eliot has a proposal for MathML for 1.3. IBM is looking for direction from TC for IBM to do an early implementation. There are 2 parts to their concerns:
1. Most editors include elements for both inline and block elements, but Eliot's original proposal seemed to be only implmenting MathML as a specialization of .
2. IBM wants a way to include out-of-line references to MathML elements; i.e. referencess to a file containing MathML markup
- Autumn Cuellar of Design Sciences (implementors of the XMetal editor); From the vendor perspective, we've included both block and inline elements, but we also have clients who want to do it all in stylistic approach. So we would support Eliot's approach, but we also support two different element types.
- Kris; What about your opinion, Eliot??
- Eliot; There are 2 different considerations at work.
1. If we do MathML as a specialization of , we wouldn't be intending to support the semantics of equations; that's independent of the form it's expressed in.
2. There are many different ways we might to represent equations, so there can't be a single pair - block and inline - of them. So the general object is to having a 'MathML' container'. There's some utility in having a built-in element for folks to use; the questions are: 'where would the elements go?' and 'how would we implement them?'; e.g. the actual implementation would probably be included in the TechComm specialization.
- Thilo; For math, you'd have things you wanted to number; how would you do that?
- Eliot; The style of that would be specific to your context. e.g. in textbook, you might have many different ways of numbering and repreenting a figure. You might have different markup designs for repreenting equations for textbooks, publishing, techdoc, etc.
- Thilo; so MathML source could be text, or MathML, or LaTeX or anything. but we need to have a way to numnber and organize them.
- Kris; we'll have to back to you and IBM, Simcha, after discussing this a bit more...
- Simcha; we definitely want osme form of numbering in the container, and some standard way of passing it through. We don't mind having a single element, we just want to know how it will go.
- Chris; I don't remember why PTC went with 2 elements, though I seem to remember that it was cleaner or simpler.
- Tom; I think XMetal uses 2 elements; Autumn would know, since Design
Sciences does our implementation.
- Autumn yes, it's 2 elements.
- Don; Tom, how would this affect your customers?
- Tom; I'm not sure, they could run a transform to move from 2 -> 1 elements, but I don't know how much of an impact that would have on them.
- Eliot; The challenge is that many folks already have integrations of MathML with DITA, and they're all different, so whichever option we choose, 1 or 2, we can't support all the legacy styles.
Another thing to consider; if someone already has an integration of MathML, they already have a specialization. The question is; did they impose the semantics of equations within that specialization? If so, that could be complicated.
- Kris; The original note from Robert included IBM users wanting to store markup separately.
- Eliot; we could specialize image to have a MathML image. We don't have a general pattern for using specializations of to reference things, but we could do it.
- Simcha; there are issues with the use of a specialization based on . We need additional markup around it for math, and there are situations when authors aren't thinking of equations as image, but semantically.
- Eliot; So the real issue is whether MathML is fundamentally a graphic image, or a repreentation of content that gets represented as a graphic image?
- Simcha; For IBM, it's usually more like SVG; it's content that get's represented as an image
- Eliot; We want o consider that requires @alt, which is the accessible part of the image.
- Tom; for XMetal, there would hae to be a script that found the external reference code and pased it to the processor. I think it wouldn't mean it couldn't deal with an image. it would be easier if it were MathML, rather than it being an image; that would require an exception. It seems better for math to be its own thing rather than it being an image. So having it as an image would make coding ugly
- Eliot; so if we define a MathML object, and don't specialize it from image, what would be specialize it from? image?, xref?, foreign? I'd think it would need to be a child of foreign.
- Simcha; It seems like there are really at least 3 or 4 kinds of markup you might want to have. So instead of having multiple MathML specializations - of image, inline, etc - there should be just one major specialized MathML element, with a bunch of subelement of that element, like foreign, rather than having multiple.
- Eliot; But representation of an equation semantically has be be separate from presentation representation.
- Don; Are we missing the definition of foreign vocabularies?
- Eliot; The requirement on is that it must be specialized.
- Kris; Can we come to some sort of consensu here?
- Eliot; I can update my proposal and provide alternatives that people can react to.
- Simcha; that's what we need to go on with.
- Eliot; It would be useful for me to have, from the TechComm community what are their typical usages and factors for equations within techdoc.
Action Item: Eliot wil update his proposal to address this, and the TechComm committee (or one of its members) will provide him with information about typical usage for MathML.
6. NEW ITEM: Clarification of @href or @keyref on element
https://lists.oasis-open.org/archives/dita/201304/msg00015.html (Kimber, 6 April)
https://lists.oasis-open.org/archives/dita/201304/msg00016.html (Nitchie, 6 April)
Resolution: Postponed to 7 May
7. NEW ITEM: glossref not possible with classifyMap.dtd
https://lists.oasis-open.org/archives/dita/201303/msg00060.html (Tivy, 19 March)
https://lists.oasis-open.org/archives/dita/201303/msg00065.html (Kimber, 23 March)
https://lists.oasis-open.org/archives/dita/201303/msg00073.html (Tivy, 25 March)
Jim Tivy gave background on this; he wasn't able to use glossref with classifyMap, and would like to know why. Typically you have your subject defs in another maps, but if you want to classify your topics in your main map with your glossrefs.
- Kris; Who in TC was involved in creation of classifyMap?
- Eliot; Typically, when we create these specializations, we're trying to be very focussed.
- Kris; So is there a need for a doctype shell for 1.3 that enables both, or should we
- Jim; There are 2 parts to classify; setting up subjectdefs, and doing refs. I don't think a map needs to include ability to set up schema, but I would ezxpect it to be able to classify topics.
- Eliot; The real question here is: why doesn't map include the classification domain? Should there be a 'generic' map that includes all domains.
- Kris; we have to stop now; can pick this up later in another
Resolution: to be continued on 7 May
closed at 12:00
-- Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]