dita — archive

[Nancy Harrison]

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 Document Name : DITA TC Meeting Minutes 20 Januarty 2015 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 : 2015-01-26 23:23:32