[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-help] Review of Stage 3 Proposals
Hi Ian I think the yield-to-topic attribute (which we changed to @source-priority, but not everywhere in the proposal is seems J ), only makes sense in the map, because otherwise you might have competing @source-priority settings in topic and map. The scenario would be where a context hook is generally used for a particular topic (and so is set in the topic) needs to be different for a peculiar Help system, so an alternative hook is set in the map. To clarify which should be used, or whether both hooks are valid, the @source-priority has to be set. And that’s the attribute that is only defined in the map. We did discuss this quite a while back; the only recent changes were to alter the name and to opt for a set of values rather than a Boolean yes/no. Cheers Tony From: ian balanza-davis [mailto:ibalanza_davis@yahoo.co.uk] Hi Tony I cannot be too much help on the specification, other than to say it seems to reflect the conversations we have had as a sub committee -- I will have to go with the views of those far more knowledgeable in this than I... Just one question, in 13060 we state: To avoid problems where context hooks defined in the DITA map potentially conflict with those defined in the topics, a @yield-to-topic attribute can be used to indicate how these potential conflicts should be resolved. This attribute can only be defined in the DITA map." Does there need to be any discussion of this enforcement? I can easily see this being misused in a topic if there is no enforcement envisaged - may not be a problem within organisations but not something to openly support I guess. Ian From: Tony Self <tself@hyperwrite.com> Hi Stan (and all) The 13060 (resourceid) proposal is similar in scope to Robert Anderson’s proposal 13008, and unless I’m missing something, the structure of our proposal is pretty much identical to his. And that’s, I guess, as it should be, because his is a proposal to add attributes to resourceid, and ours is a proposal to add attributes to resourceid. But I have a nervous feeling that I must be missing something? 13061 (ua-window) is more complicated, because it is a new element. However, it is not as complicated as 13097, which is an entire new information type. Bearing in mind I am pushing the envelope of my capabilities here, with a new ua-window element within the map element, will there be anything other than map.mod that needs to be changed in the DTDs? Unless we are going to pull ua-window out into its own module (and as I say, I don’t have the requisite DTD skills to be definitive here), the new element should only impact that one file, shouldn’t it? I used the navref as a guide in this regard, as I thought it was a similar element in the sense that it only lives in the map and has no “contains” elements. The navref element is only mentioned in map.mod and mapgroup.mod. The ua-window element won’t be valid in the mapgroup elements (topicgroup, topichead, etc) because windows are defined way at the top of the map structure. I went through map.mod in more detail, though, and as a result, I have expanded the modified DTD section of the proposal to show the sections affected, and bolding our new stuff. In Section B of the Typical Stage 3 Outline information, I think the feature.mod, feature.ent and feature.dtd are therefore not applicable for our proposal. I wonder whether you were also suggesting that we need an Architectural Specification change topic (Secction C Part 1). My view is that we only need to make changes in the Language Reference, but I am not firm on this either. I have found that we needed to change one of the topics in the Architectural Spec, and I’ve added this to the proposal too. I’ve attached the latest HTML version of 13061 (windowing) so you can see what I mean. What do you think? And I also put together a new topic about Help and user assistance support for the Architectural Spec, and I’ve added that to the 13060 (context hook) proposal, even though it refers to both resourceid and ua-window. I think this is a useful addition… hope you all agree. Tony From: Stan Doherty [mailto:stan@modularwriting.com] Hi Tony -- Mea culpa -- I have been heads-down this past week finishing a talk (DITA and HTML5 jumpstart) for Joe's WritersUA conference next week. What you have in the current Stage-3 documents is all good, but there quite a bit of additional material for the complete Stage-3 package (see outline below). Most of the missing material should be relatively easy to develop and I am able to make time this weekend+Monday+Tuesday to help with *.dtd, *.mod, *.ent, doc updates -- whatever. I can do a skypecall tonight (Thursday 07:30/EST or later) or tomorrow night to coordinate if you'd like. I have also attached a few of the submitted Stage-3 PDFs from TechComm or from other TC members. * proposal-13097-Troubleshooting_Stage3_08oct13.pdf: Bob Thomas' Stage-3 proposal for the new Troubleshooting elements and topic. Perhaps the most complete of the set (including a plug-in). domain. It may be decent model for <ua-window>. * Proposal_13008_resourceid_Stage3.pdf: Robert's @appid proposal for resourceid. Could be cloned in some sections for 13060.
new elements. Perhaps a model for <ua-window>. /stan TYPICAL STAGE-3 OUTLINE -------------------------------------------------------------------------------------- A. Stage-3 Proposal Template > On October 23, 2013 at 6:24 PM Tony Self <tself@hyperwrite.com> wrote: Stan Doherty
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]