dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 20 Januarty 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 26 Jan 2015 23:23:47 -0800 (PST)
Submitter's message
ActionItems:
1. Robert will update spec wrt dita-use-conref-target so it states that if you allow the token, it's allowed anywhere not forbidden by grammar files.
2. Robert will add the first sentence from Eliot's suggestion to the list of chunking rules.
3. Any TC members with suggestions to make on resolution of subjectscheme issues should email them to the list.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 20 January 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: Joann Hackos, David Helfinstine
Standing Business
=================
Approve minutes from previous business meetings:
https://www.oasis-open.org/committees/download.php/54857/minutes20150113.txt (13 January, Nancy Harrison)
Proposed by Kris, seconded by Bob Thomas, approved by TC
Subcommittee Reports
none scheduled till Feb. (except possibly Michael on Lightweight DITA:
Announcements
Business
========
1. Action items
- Action items from 2 December 2014:
Eliot: Move RNG-to-DTD-XSD generator code to GitHub (on hold)
- Action items from 16 December 2014:
Don: Schedule meeting to talk about dita.xml.org (moving ahead on this)
- Action items from 6 January 2015:
Robert: Remove mentions of XML Data type from LangRef topics
Robert; making progress, still some to go, hopefully by end of day
Robert & Eliot: Discuss resolution of "Branch filtering: DITAVALref as child of map"
- Action items from 13 January 2015
Nancy: Schedule meeting with Jean-Jacques Thomasson (pinged Kris for list of participants and contact info)
Robert: Send e-mail to list clarifying what is involved in the "DITAVALref as child of map" question (working on this)
Kris: Send e-mail to list with new version of "Constraint rules" (will do within a few days)
2. Targeted reviews progress: January - February 2015
Link to DITAweb: https://ditaweb.com/oasis-dita|DITAweb
Progress on conref: https://lists.oasis-open.org/archives/dita/201501/msg00026.html
Kris; comments are closed; all comments have been dispositioned and addressed.
Robert; there was a lot of participation, so a lot of editing to do; we spent time on every single comment. We were really looking for reviews by people who hadn't looked at it before; those helped us really clean up the language.
Kris; it was time-consuming but fruitful; if you're reviewing, please read the PDF or .chm file before commenting in DITAWeb; sometimes the DITAWeb rendering is misleading, where the PDF and .chm is more accurate.
Robert; e.g., if you have a DL in DITAWeb, it looks like a section followed by content.
Kris; we've cleaned up this part of the spec substantially
Progress on constraints: https://lists.oasis-open.org/archives/dita/201501/msg00034.html
Kris; we're working on that; hoping to open up review of conditional processing material.
Processing: All voting members are asked to participate
Jan 06-12: Conref (8 pages)
Jan 13-19: Direct addressing
Jan 20-26: DITA linking
Jan 27 - Feb 2: Keys
Feb 03-09: Conditional processing
Feb 10-16: Branch filtering
Feb 17-23: Keys revisited
Configuration, specialization, and constraints: Volunteers requested
Jan 06-12: Constraints (19 pages)
Jan 13-19: Constraints (19 pages)
Jan 20-26: TBD
Jan 27 - Feb 2: TBD
Feb 03-09: TBD
Feb 10-16: TBD
Feb 17-23: TBD
3. New item: Question about -dita-use-conref-target in unexpected places
https://lists.oasis-open.org/archives/dita/201501/msg00046.html (Anderson, 15 January 2015)
Robert; this came up based on errors tools were giving. this token is very rarely used; it's there to enable conref on elements that require @s. It's an edge case, and since we have fewer required @s now in 1.3, if you have an attribute defined as a specific set of values, is this valid even if it doesn't conform to that set of values? Eliot and Chris think that it should be allowed unless the grammar forbids it. Any other comments?
[none]
Robert; I'm OK with their comments, so I'll change the spec to match their comments.
Tom; I can confirm that it's an edge case. I think we don't allow it, but no customer has ever complained, so I think we'd get away with it.
Robert; especially with tgroup, that's really an edge case. It came up when we had a lot more required attributes; now that we have fewer, there's less need for it.
Eliot; DTD does in fact allow it.
Robert; yes, no change needed to DTD, it's just clarifying the spec.
Kris; We'll take the lack of any other comments or objections to indicate we should change the spec to allow what the DTD already allows.
ActionItem: Robert will update spec wrt dita-use-conref-target so it states that if you allow the token, it's allowed anywhere not forbidden by grammar files.
4. New item: Explicit Prohibition on Nested Tables?
https://lists.oasis-open.org/archives/dita/201501/msg00049.html (Kimber, 16 January 2015)
Eliot; I thought nested tables were disallowed based on disallowing of entrytbl. But I couldn't find anywhere where it's explicitly disallowed, just implicitly through the use of Exchange table model. So do we need to say anything explicitly?
Robert; I think we should leave it alone.
ChrisN; Most people don't know enough about Exchange table model to make Eliot's inference, and people now use it, so we need to leave it in.
Robert; we shouldn't add more caveats to the spec.
Eliot; I'm happy to go with that, it's just that rendering nested tables is so hard. My concern is with tools not being able to be 'conformant' if it doesn't support this.
Kris; i think we'll just leave this be.
[TC agreed with this; spec will be left as is wrt this.]
5. Review #2 comments:
- New item: Branch filtering: ditavalref as child of map
https://lists.oasis-open.org/archives/dita/201412/msg00028.html (Anderson, 8 December 2014)
Kris; we've had substantial discussion on this; Robert emailed a summary this morning
Robert; if we have a map with multiple ditavalrefs as children of that map, how does that work? I don't think people have had time to really look at this email, so can we discuss this next week?
Eliot; I read it, but would be happy to push off till next week
[will discuss next week]
- New item: How to treat a keyscope with multiple names
https://lists.oasis-open.org/archives/dita/201412/msg00020.html (Eberlein, 7 December 2014)
Kris; I don't honestly remember issue
Robert; it comes down to a language issue, I'm not sure if 2 diff versions actually have diff. meanings. keyscope can take one or more names; if you use it twice, you're only creating one scope. Jarno says 'with keys you can create multiple keys, so why not with keyscopes?'
Eliot; there's one scope, with multiple names, and that scope determines the values of all the keys defined in that scope, A key is always a binding from one name to one resource, so you can't have multiple keys for a single key name, but a keyspace is multiple bindings, so you can have as many names as you want.
Chris; I kind of see Jarno's point. The spec uses a particular conceptual model to describe behavior; Jarno's is an alternate conceptual model. But taking Jarno's would require more work than we want to do, and would invite confusion.
Robert; I support the least confusion.
Resolution: leave current text as is.
- New item: Chunking: resource name selection based on @keys
https://lists.oasis-open.org/archives/dita/201412/msg00027.html (Anderson, 8 December 2014)
Robert; now, there's a list of rules to follow in creating chunk names. Eliot suggested a new rule in case you're using keys. I think that's perfectly logical. I'd prefer to stick with Eliot's first sentence, though his other stuff is still allowed. So we add a new rule to creating chunk names (Eliot's first rule)
Eliot; I'm fine with that.
Resolution: no objections; Robert will add the first sentence from Eliot's suggestion to the list of chunking rules.
- New item: Subject scheme
https://lists.oasis-open.org/archives/dita/201411/msg00078.html (Eberlein, 28 November 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00025.html (Nitchie, 8 December 2014)
Kris; The spec never discusses key scope implications of a subjectscheme map.
Chris; keys used in subjectscheme are fundamentally different things than other keys, so when you reference a taxonomy map from a regular map, you suddenly have a bunch of keys that have nothing to do with navigation. If you want to avoid this, wrap taxonomy keys in a keyscope.
Eliot; I would be uncomfortable treating subjectscheme maps as anything special. also 2 use cases, subjectscheme map as parameter, and subjectscheme map as included within a regular map. so we don't want to process things diffferently.
Don; I look at it differently. as a creator of a particular specialization, so if i wanted a map specialization then I could designate that this wasn't a publishing role, but a procesing role.
Eliot; but keys are about addressing, and we've established a rule that addressing rules should be invariant, particularly keys and key spaces.
Chris; I can see it both ways... i think we just need to be clear and have a non-normative note that if you have a taxonomy map you may run into this. Should we default to keyscope on subjectscheme element? But it is what it is.
Robert; if we have a scope for a key used as an attribute value, will processors expect the attribute to be 'keyscope'.'name'?
Kris; I'll respond back to Eliot's comments. I think; I'm very leary of anything that makes them more complicated to use. We can look at 1.3 spec subjectscheme map.
Robert; I think going with keyscope.... would make subjectschemes much less usable
Eliot; in 1.2 if you use subjectschemes, you have to make sure subjectscheme key names don't interfere with key names in other places.
Chris; what was the original intent?
Eliot; a good question. if intent was for purpose of validating iterations, treat subjectscheme as it was to validate names; then use of keyscope doesn't matter, it will treat subjectscheme as a standalone space of names, but that's separating the two uses of keys.
Jim Tivy; i think we should keep it simple and if you want to separate them, just put a scope on subjectschemes.
Kris; but that will break current implementations.
Chris; but what would be processing implications?
[go back to mail for clear explanation]
Eliot; in 1.2, if I have 2 subjectscheme maps and
Robert; the spec says subjectscheme maps and other maps are additive
Kris; this is a question I raised to TC 2-3 years ago
Chris; but we're not saying that 'it follows keyspace precedence rules'; no one thinks they're the same.
Eliot; there's 2 different domains of processing, 1. normal key space, and 2. attribute validation domain, and they're different.
Kris; and a lot of normative rules are buried in 1.2 spec in langref examples; one reason we substantially revised that for 1.3
Kris; our previous resolution was that given a subjectscheme map that referencess a root map, standard key resolution happens.
Eliot; so in 1.2 first definition wins, in 1.3, since we have key scopes, you'd have to use them.
Chris; so suppose I have a key in subjectscheme that conflicts with a key in a regular map, if I qualify it, then none of regular keys work, since they don't have the scopes
Eliot; all subjectschemes, whether they're keyscope-qualified or not, form a single space.
Kris; please send email to list with your suggestions.
meeting closed at 12:00
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]