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 April 2013 uploaded


Submitter's message
Notes from meeting of April 9

===============================================
Minutes of the OASIS DITA TC
Tuesday, 9 April 2013
Recorded by N. Harrison

regrets: Adrian Warman, Seth Park


Standing Business
=================
Minutes from last meetings:
https://lists.oasis-open.org/archives/dita/201303/msg00087.html (26 March, Harrison)
https://lists.oasis-open.org/archives/dita/201304/msg00008.html (2 April, Harrison)
Proposed by Kris, seconded by MichaelB, approved by TC

Subcommittee Reports:
None:
(DITA Adoption TC beginning of May)

Announcements:
Don mentioned OASIS's recent 20th anniversary


Business
========
1. DITA 1.3 progress
Progress between April 1-7, 2013:
https://lists.oasis-open.org/archives/dita/201304/msg00017.html
Update on deadlines:
https://lists.oasis-open.org/archives/dita/201304/msg00018.html
Trello Board:
https://trello.com/b/gPKH0OcF
As of 7 April 2013, the following voting member still needs to join: Seth Park
Kris went over progress status; some deadlines will be updated.


2. DITA 1.3 proposals, stage 2: http://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage2

[for today, reversed order of discussion and vote, since discussion of 13004 was expected to be, and was, lengthy]

Ready for vote: Voting options are "Yes," "No," "No objections," "I don't understand the proposal," and "I have reservations"

Proposal 13090: DITAVAL style enhancements (Nitchie)
https://lists.oasis-open.org/archives/dita/201304/msg00007.html (HTML, updated 2 April after TC meeting)
https://lists.oasis-open.org/archives/dita/201304/msg00006.html (DITA, updated 2 April after TC meeting)

ChrisN proposed, seconded by Stan

Results:
yes: Robert Anderson, Deb Bissantz, Michael Boses, Don Day, Stan Doherty, Kris Eberlein, Nancy Harrison, David Helfinstine, Eliot Kimber, Tom Magliery, Chris Nitchie, Michael Priestley, Adrian Warman
no. obj: Dick Hamilton


Ready for discussion:
13004: Scoped keys (Nitchie)
https://lists.oasis-open.org/archives/dita/201304/msg00011.html (HTML)
https://lists.oasis-open.org/archives/dita/201304/msg00010.html (DITA)

Chris gave overview of his updated proposal; the basic change is a new attribute, @keyscope; when it appears, it inherits key definitions from its parents' scope. Previously, if you wanted to address a key def, there was no way to do it; you could only use keydef within a scope where it was declared; now keydefs are available when they're specified with the scope name, e.g.
'scopex.foo'

Jim Tivy asked; in this context, what is the meaning of the term 'scope'?
Chrish; For this proposal, it's an element in a map that contains key defs that contain content. I want to restrict discussion here to this meaning.
[It was agreed that the discussion would restrict itself to that meaning, and that there can be no 'implicit' key scopes.]
Jim Tivy, Eliot and Chris had some discussion about the usage of the terms 'key scope' and keyspace; Kris referred anyone with similar issuez to the TC's FAQ on keys at http://dita.xml.org/resource/dita-tc-faq-about-keys.)

Kris asked MichaelP if he had any issues with the proposal, since he did originally. Michael felt that Chris's latest proposal addresses his concerns, but said he would need to go back and review our earlier discussions. He did have one minor issue; for a socpe separator Chris is using periods; he'd rather use slashes, since we use them in parallel usages.
Chris; The problem with that is that we end up overloading the slash, You could use both in one _expression_ and get confusion.
Eliot; also, we'd then have the problem that people would assume they could create a sequence of them separated by slashes. OTOH, dot ('.') is also not so good. I think we need a character that's either not now allowed in key names, or is rarely used.
Chris; The fact is that you can use a dot in this or a literal keydef, so it doesn't force anything. I'm leery of anything that makes a key ref have to be aware that it's in a scoped environment.
Eliot; but if you have a name that already uses dots. Now we include those maps into a root map, and call the scope using a dot. So does that make the already existing keydefs with dots behave differently?

[Eliot, Michael, and Chris discussed the implications of this issue - using a dot as a delimniter - using a sample scenario. They agreed that it required more thought and discussion, and the they would beef up the sample scenario to make it a good discussion reerence via email. There is some concern that legacy content may be using characters in defining keys that would be compromised depending on what delimiters we specify for defining key scopes.]

- ChrisN; My metaphor on scope is that "'scope' puts a fence around the keydefs and they can't get out."
- Eliot; I'm wondering what are the implications for addressing keys in map1 from map2. We need to write down these scenarios to be clear on them.
- Kris; is this something we need to take to the email list?
- Eliot; We need to clearly state the issue; if we use chris's proposal, when there are scopes to find, should the first dot always be a reference to key scope? Suppose we have a 1.2 map with dots in keydefs. In 1.3, if you don't define scopes, they don't change. But if you define a scope with a name, then any keydef that had that scope name at the beginning, is in that scope.
- Chris; But only from outside that scope, from within, it's still the same.
- Kris; Eliot, are you asking for an enhancement of Chris's proposal to explain what happens in this case?
- Eliot; I think so, we need to understand, among other things, what happens when you have content that comes from 1.2 to 1.3.
- Kris; and where there might be breakage.
- Eliot; Breakage can't be a deal-killer, the real question is whether there's anything about his proposal that's going to cause unexpected behavior.
- Chris; not necessarily.
- Eliot; It's a challenge; it doesn't provide a way to express keys within an external scope.
- Chris; I think it can be leveraged to do that, but we need to discuss that another time. I'm just extremely distrustful of any new syntax in keys.
- Kris; This is a good time for a segue to talk on complexity; Chris's proposal entails a major cost to vendors.
- Robert; From the DITA-OT perspective, this is the most costly item in 1.3, so it is a fair amount of work.
- Chris; as someone who's written DITA processors, it will be tricky but not impossible. Given the new idea of contributing implicit keydefs to parent scope, it now becoomes possibe to have a set of fully qualified constructed global keyspaces with gualified names, replacing unqualified names with their qualified equivalents.
- Eliot; It makes sense to me, but if you can construct one keyspace, you can create a multiple of them; the challenge is to be aware that there's now a hierarchy of them.
- Chris; the trick is figuring out the effective keyspace for a given reference.
- Eliot; the current toolkit doesn't do anything in a map-aware way for final processing; keyspaces would change that.
- Don; we might want to get some input from outside community on this, since the OT isn't the only processor out there.
- Eliot; I've already talked to Jeremy (Dita2Go)
- Chris; With regard to complexity, I've heard that this is a essential feature for 1.3, and it's not simple to implement.
- Kris; we're probably all in agreement, but we need to touch on complexity issues.
- JimT; there's an issue of a complexity of understanding, not just implementation.
- ChrisN; There's a concept implicit in DITA 1.0 that isn't called out, the concept of 'key name'

Resolution; discussion to continue via email; possible vote on April 23rd.


5. 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)

Kris; Does this item have a quick answer, or do we need to pick this up on the call in 2 weeks?
Eliot; I brought up the question; I was hoping for a quick answer, but ...

Resolution; discussion this item on April 23rd.



closed at 11:59




-- Nancy Harrison
Document Name: DITA TC Meeting Minutes 9 April 2013

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: 2013-04-23 03:08:13



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