and xmlmention domain.
Eliot; there's a small issue with the way the OT is architected; can override any extension, but ...
- Style sheets (Thomas)
- Transformations (Thomas)
- Content (Anderson and Eberlein)
- XML grammars (Kimber)
Eliot; not sure what I was expected to do
Kris; this is an open agenda item, do you have any new work to report on?
Eliot; no, none, I need to ping Robert on the details of what the latest comments require; I've been working on DITA-OT 1.x plugins to allow 1.3 contents to be handled.
- Related e-mails:
o Build results uploaded
https://lists.oasis-open.org/archives/dita/201504/msg00180.html (Eberlein, 28 April 2015)
o Need feedback about file names and footer info for CHM and HTML versions of the DITA spec
https://lists.oasis-open.org/archives/dita/201504/msg00173.html (Eberlein, 28 April 2015)
https://lists.oasis-open.org/archives/dita/201505/msg00030.html (Ensign, forwarded by Eberlein, 5 May 2015)
o Work required to get a working draft of the spec out
https://lists.oasis-open.org/archives/dita/201504/msg00088.html (Eberlein, 14 April 2015)
3. Targeted reviews progress: January - May 2015
Schedule for targeted reviews:
Progress on branch filtering: Comments assigned dispositions; editing in progress
Processing etc.: All voting members are asked to participate
April 28-May 5: Keys (25 pages, including 15 pages of examples) -- CLOSED; editorial work almost completed
TBD: Direct addressing
Configuration, specialization, and constraints: Volunteers requested
TBD: Configuration and specialization
Kris; we're very close to having resolved and worked in all comments for keys review
Robert; a lot of comments, >8 hours just on the phone, plus actual editing to resolve things; lots of very careful changes; overall sense from review was mixed; this part of the spec is aimed at implementors and was always aimed at implementors, but it should still be written so other tech folks can understand it. This stuff is the most technical in the spec; those who have implemented keys processing understood the details best.
Kris; that's a fair summary, enough so we've added a non-normative note indicating that the audience is implementors, not primarily users. This will never be a keys tutorial.
Robert; ditto; we can't turn it into a tutorial; if we did, info would appear in many places, which we're trying to avoid.
Kris; one thing we can and will do is to produce output with rev marking turned on, except for examples.
Robert; I'll try to do that as well.
Kris; OTOH, I'm happy with where the content is as well.
4. Report on demo of DITAweb for dita.xml.org
5. New item: Topic nesting in troubleshooting topic
https://lists.oasis-open.org/archives/dita/201505/msg00020.html (Thomas, 4 May 2015)
Kris; I thought we had handled this item
BobT; there's just one change; Eliot and I had an exchange on list; rather than set nest-info-types, better to just allow task within troubleshooting topic, it's kind of an edge case.
Kris; any discussion? any objection to changing content model?
[none from TC]
ActionItem; Eliot to make that change to grammar
6. New item: DITA Pharmaceuticals
https://lists.oasis-open.org/archives/dita/201505/msg00001.html (Kravogel, forwarded by Eberlein on 1 May 2015)
Call with Chris Kravogel scheduled for 11 May at 9 AM ET
Don; we've worked with ChrisK before; he dropped out of TC involvement for a while, but has come back with ties to pharma standards. There's a somewhat new standard (ISO) (IDMP standard) for data model, not markup, and it's being applied to DB or XML implementation; ChrisK applied it to DITA using a specialization to define IDMP; Kris and I were impressed with its fidelity to DITA sppecialization mechanisms. This brings an opportunity to enable pharma manufacturers to use DITA. ChrisK will provide slides to the TC.
Kris; It seemed like it was very easy for him to map IDMP to DITA; he wants to pursue whether this could be a joint work product between ISO and OASIS; he'll come to 5hw TC and reprise the presentation he gave us.
Don; It gives us the possibility of moving DITA into a new usage of DITA,
Kris; One of major players on the IDMP ISO committee is the US FDA, This is also a good place for us to work out kinks of DITA 'profiles'.
Kris; if any are intersted, let me (Kris) know
7. Continuing item: Need to include a "Domain constraints integration" section in the XML grammar files?
Kris; we talked about this last week, but left it open till Eliot was here. should we add such a section, and if so, how easy would it be?
Eliot; we also don't have the corresponding structural constraint comment so there's already a precedent, so if we add one, we should add both. It's probably clearer to have the sections, but the current state is that we don't have either section in shells that don't need them.
Robert; in all of my testing, I never looked for that. I think spec says/implies they will be there.
Eliot; either it got missed, or we made a decision.
Robert; It was not a TC decision, it just got missed.
Eliot; it's not hard to add them as comments, and I certainly have no objection to them being there.
Kris; it would be helpful, and would let us have one clear topic on 'what's in your document doc shells; here's what's there and why.
Kris; any objections?
ActionItem; Eliot will update grammar to produce empty sections in doc shells
8. New item: Question from keys review: addressing non-topicref elements in a map
https://lists.oasis-open.org/archives/dita/201505/msg00040.html (Anderson, 7 May 2015)
Robert; The text in question is about the syntax for using keyref:
"For references to non-topic elements within topics and non-topicref elements within maps, the value of the @keyref attribute is a key name, a slash ("/"), and the ID of the target element (for example, keyref="topic-key/some-element-id".) "
It's the same as from 1.2; is this appropriate? This only makes sense if the key is in a map; otherwise, it doesn't. My remaining confusion is that now, the reason we have this, is that from a map, you can't address the elements in a topic, only the topic level itself, so a key can only represent a topic, not anything lower. OTOH, it's legal to connect anything in a map, and therefore to a 'map/element_id'
Don; Are you saying a topicref could be an XPath to anything in a topic?
Robert; NONONO!!! a key can correspond to a topic, but not in a nested topic.
Eliot; And if a key is bound to a map, you can bind it to any element in that map.
Robert; So we have 2 ways to do the same [silly] thing, but I don't care
Kris; I think we're OK if we just remove the phrase highlighted in Robert's email,
Don; are there any backwards-compatible issues?
Eliot; any process that took advantage of this would have to be reworked, but chances of any process like that existing are small.
Kris; Is this a bug fix?
Kris; It's either a bug fix or a spec clarification.
ActionItem; Robert will fix the spec to remove that phrase
9. New item: Question from keys review: processing keyref for text or link text
https://lists.oasis-open.org/archives/dita/201505/msg00042.html (Anderson, 7 May 2015)
Robert; The language in 1.2 for figuring out link text wasn't procedural; in 1.3, I consolidated it to make it more usable. It seems as though you can use keyref on the content of an element allowed inside 'topicmeta (author, source, data, data-about). I think that was originally intended, and both Eliot and Chris agreed this should be a rule; does the TC agree? also, where does it go in priority list?
Eliot; I agree with your analysis and would defer to your judgment.
Robert; I did not design this; i'm just trying to clear up the language. it was designed by committee, and I wasn't even on the committee...
Kris; Robert, you suggest slottng this new rule between 1 and 2?
Robert; yes; I've always been confused by distinction between 2 and 3.
Kris; any objections?
[none from TC]
ActionItem; Robert will fix content as indicated
10. New item: Question from keys review: cascading of metadata
https://lists.oasis-open.org/archives/dita/201505/msg00041.html (Anderson, 7 May 2015)
Robert; The text in question, about combining metadata when @keyref is used on 'topicref':
"Content from a key-defining element cascades to the key-referencing element following the rules for combining metadata between maps and other maps and between maps and topics. The @lockmeta attribute is honored when metadata content is combined."
Chris pointed out that the rules for map-to-map cascading are subtly different than the ones for parent-child topicrefs. I don't know which should apply; don't know if we can combine them; I don't think we can know how it was implemented.
Eliot; I wrote the original, the intent if you have keyref is that refs to a topicref in a chain of keyrefs, if there are topicrefs in a sequentional relationship, intent was that cascading would flow backaards the same way as though those topicrefs were nested.
Chris; I'd agree based on the language; I don't know if we need to make a language change and risk backwards compatibility concerns.
Robert; There is the possibility of ending up with subtle differences, but the risk is low.
Eliot; can we clarify it?
Robert; if there's a backwards compatibility issue, it will be noticed in implementation, not in source.
Eliot; what does the DITA-OT do?
Robert; I don't know offhand
Robert; we can call this another fix and document it in our list of fixes.
Kris; to the extent that we have one.
Nancy; what's being proposed??
Robert; to change the language to reflect that cascading works as it would from parent topic ref to child topicref. and if we do, i'm not sure where to put that. Or we leave it as is, and all interpretations are happy and valid. we're not ever sure what it means.
Kris; in which case, we do add it to our list of fixes for 2.0.
ActionItem; Kris wil add it to 2.0 fix
12 noon ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]