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 22 July 2014 uploaded

Submitter's message
Minutes of the OASIS DITA TC
Tuesday, 22 July 2014
Recorded by N. Harrison
link to agenda for this meeting:

regrets: Joann Hackos

Standing Business
Approve minutes from 2 previous business meeting:
https://lists.oasis-open.org/archives/dita/201407/msg00025.html (1 July, Nancy Harrison)
https://lists.oasis-open.org/archives/dita/201407/msg00026.html (15 July, Nancy Harrison)
[both] proposed by Kris, seconded by Dick, approved by TC

Subcommittee Reports


1. DITA 1.3 progress
- First spec review (Eberlein & Anderson)
Kris; Kris reviewed all open comments in arch spec, and addressed all she could, and moved all others into the draft spec as draft-comments; those relate to keys/key scopes. she, Robert, and ChrisN reviewed and discussed those sections, and are in process of fixing that material, after which they will ask others to review the new material.
- Transformation utilities and DITA 1.3 grammar files (Kimber)
nothing new...

2. New Item; bugs and quirks in 1.3 DTDs.
Robert; there is a bad content model in troubleshooting.dtd; it needed to be fixed in RNG to regenerate correct DTD
Eliot; the work I did just before i went on vacation should have fixed that bug, so I need to check to see why the fix isn't showing up. I'll verify that.
- Kris; while youre doing that, there are some domains to add to some of those other doc shells
- Eliot; I was just waiting for clear direction from the TC to update everything
- Kris; Robert can you update your tables in your doc shell topics, as recorded in last week's minutes, to indicate what should be where?
- Robert; will do.

3. New item: Review #1 comment re subjectdef elements and key scopes
[issue brought up on list by Jarno: should subjectscheme keyscopes be processed same way as regular key scopes?]
Kris; need to be able to keep scopes values; original specified @keys value would be enumerated value when keys within nested subjectschemes are being evaluated
- Eliot; I can't see any reason for disallowing keyscopes on SS's. They should be processed the same way for all maps on whatever specialization.
- Tom; it seems like you'd have different scopes for different schemes, but they should all be processed the same way.
- Eliot; for purpose of defining enumerated values, what is the process for defining keyscopes?
- Kris; in work were doing to look at definitions for keys, key scopes, etc. we haven't been considering use cases for using them within subject schemes. Robert and Chris, how do you think that will complicate the usage?
- Robert; not sure that having scoped keys with refs vs [non-scoped] keys changes things...
- Kris; the way something can be used to control the @or component attr. then products are bundled into products with different sets of components. It could create a combined SS and manually untie them. It's easier if we can get automatic validation of the correct component just by defining the scope within a map. Then we can control order of a specific list, or bind element/attribute pairs, that could be an issue.
- Robert; we might restrict values for a specific audience.
- Michael; if we can't figure out how to make it work, its not a dealbreaker, but it's a nice-to-have
- Robert; I'm not seeing how it would work to set a scope on your scheme, what would it restrict?
- ChrisN; what if you reference keys from narrative map?
- Robert; you'd want your scope to cover both scheme and content; not have different ones for scheme and content. Not that you could even do that, but even if you could, it would be the harder way to do it.
- Kris; as Eliot said; if you use keys and taxonomy, would expect IDs to be the same; so should we disallow definition of key scopes on subject schemes?
- Eliot; we definitely need to define what the implications of using key scopes in subject schemes are.
- Michael; we need to be able to import someone's subject scheme, within my master SS; we want to import it with a scope within my master SS.
- JimT; what does it mean to use a subjectdesc? either a subjectdef, or enumref; coud add scoping on subjectdefs, but referencing of them is typically not done from nested context.
- Michael; how do you pull one SS into another?
- Kris; use schemeref
- Michael; so I can see putting scope on schemeref, but leaving it off other places.
- Chris; this prevents clashes from siblings, but parent overwrites children keys.
- Michael; does it make sense for SS to reference topics? for some things that might be appropriate, e.g the scoped keys proposal.. or in a glossary.
- Kris; seems clear that this is not something we considered at all when we approved/discussed the scoped keys proposal.
- Michael; we can have consistency (having @) or simplicity (removing @) we don't replesent all users.
- Kris; we would have to explore ramifications for enumerated lists.
- Eliot; we already need to think thru SS at large, this is part of that.
- Kris; I'm not necessarily arguing for simplistic approach; just aware of points of complexity; SS is one of the least-used aspects of 1.2, unfortunately, and the spec around it is very poor.
- Robert; in terms of us cleaning up keys stuff, this is something we'll have to address either way; whether it's in SS or not, that complexity has to be addressed; issue has to be addressed in spec either way.
- Kris; any thoughts from other folks about best way to move forward in addressing this issue?
- Robert; is it in doctypes now?
- Kris; Eliot , is keyscope currently available in SS?
- Robert; whichever way it is, we should leave it for now; we'll have to deal with it.
- ChrisN; we didn't mandate all specializations?
- Robert; no, we didn't nvestigate whether it had special impications for SS.
- Eliot; it seems like I didn't add it to SS; each map is special.
- Chris; my thoughts; absent a really compelling use case, then leave it off, since it sounds like it's a stretch to put it in.
- Michael; one caveat on that is; having something that isn't consistently there adds its own kind of complexity.
- Eliot; yes; if we leave it out, we have to explain why we left it out.
- Michael; not a lot of users of SS feature
- Robert; there's a different issue, i.e. of adding things where they don't have a good use case.
- Michael; but we've been consistently putting things in that we originally kept out.
- Kris; I think the 3 vendors who would be likely to implement SS would sigh in relief if we left that out.
- Michael; can you ask them?
- Kris; yes, I will
- Robert; I say we don't make a final decision right now.
- Kris; Michael, you're the only person raising use cases for using it in SS, or on schemeref. Can you post your use cases with list?
- Eliot; I have cients with multiple taxonomies that I represent with SS.
- Kris; can you sent out concrete use cases and examples so we can look at them?
- Eliot; I need to look at what the current spec says about enumeration
- Kris; note that I'm in the process of rewriting arch spec on SS.

5. On-going item: DITA 1.3 webinar, jointly sponsored by DITA TC and DITA Adoption TC
We have new dates; webinar on Thursday, Aug 7, at 11 am ET, rehearsal on Monday, Aug. 1, at 10:45 am
Kris; Stan, do you have an update on slides?
Stan; I have slides on the following sections:
Chris, scoped keys
Mark, L&T,
Bob, Troubleshooting
TomC, rel mgmt
Robert, branch filtering
Kris; we need help with polishing presentation.
[discussion of slide formats]

closed at 11:59

-- Nancy Harrison
Document Name: DITA TC Meeting Minutes 22 July 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-08-05 05:03:53

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