Re: [dita-help] Help Features in DITA 1.3

[Scott Prentice <sp10@leximation.com>]

Could this be handled in an "outputclass" sort of way? The author would 
specify some sort of key that maps to the actual window definition 
elsewhere. My concern with window definitions is that there are so many 
properties to define. I suppose that it could be just a single attribute 
value where you specify the whole string of properties at once (I can't 
remember how the proposal was set up), so it's not much impact to 
support one additional attribute (hmm, I should review the spec, eh?).

However, I think that the examples of form embedded the content that you 
cite are actually quite problematic. It would be nice if image sizing 
wasn't tied to the image element and tables would be much nicer if their 
properties also weren't hard-coded. When publishing to various 
deliverables, these hard-coded values seldom translate well. It would be 
nice (OK, it would certainly add to the "complexity" issue) if there was 
some sort of intermediate place to define these values. Perhaps set up 
some sort of key-based lookup mechanism that could be tied to ditaval 
filtering that let you specify the image size and table properties (and 
window definitions), then just reference that via the key.

Granted .. the window definition issue probably isn't as bad as tables 
and images, but it doesn't seem unlikely that you might want multiple 
window definitions for different types of online output.

...scott



Tony Self wrote:
>
> Greetings Paul, Ian and all...
>
>  
>
> It is absolutely true that window definitions are an output 
> requirement. The separation of content and form isn’t perfect, so in 
> many situations in DITA, form has to be embedded in content. For 
> example, in DITA mark-up, a table has column specifications, an image 
> has dimensions, and an image map can be defined. The reason for these 
> “form” inclusions in the source is presumably that these attributes 
> cannot be applied automatically during the publishing process.
>
>  
>
> That’s where I think window definitions fit in. For example, if you 
> want a CHM output from DITA to include secondary window features, 
> these features have to be defined somewhere in the source. To be able 
> to produce a similarly featured CHM to that produced by a HAT, the 
> information in the HAT’s project file has to be specified somewhere. 
> (Although some of that information might be specified – and stored – 
> in the publishing build file.)
>
>  
>
> In summary, it’s a dilemma.
>
>  
>
> Tony Self
>
>  
>
>  
>
>  
>
>  
>
> *From:* Paul O'Rear [mailto:paorear@microsoft.com]
> *Sent:* Wednesday, 8 December 2010 8:31 AM
> *To:* ian balanza-davis; Goolsby, Chris; tself@hyperwrite.com; 
> dita-help@lists.oasis-open.org
> *Subject:* RE: [dita-help] Help Features in DITA 1.3
>
>  
>
> I was thinking the same thing about window definitions – the reflect 
> more an output requirement than an inherent feature of the content.
>
>  
>
> *From:* ian balanza-davis [mailto:ibalanza_davis@yahoo.co.uk]
> *Sent:* Monday, December 06, 2010 7:34 AM
> *To:* Goolsby, Chris; tself@hyperwrite.com; dita-help@lists.oasis-open.org
> *Subject:* Re: [dita-help] Help Features in DITA 1.3
>
>  
>
> Greetings all
>
> I would concur that the context hooks should be built into the core 
> content model, but I think we would need to be mindful of the scope of 
> the hooks to ensure some form of uniqueness in the final output.
>
> I am not so sure about the window definitions. To me these feel more 
> like a processing requirement, and I am not sure that it is good 
> practice to place format-specific information in the source. 
> (Pretending "print" does not exist on topicrefs...)
>
> I agree that the standard is looking complex, and I suspect can only 
> get more so.
>
> As an aside, I work with SMEs rather than (classically-defined) 
> authors who found version 1.1 complex. You can imagine how they will 
> react to 1.2
>
> Ian
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* "Goolsby, Chris" <cgoolsby@ptc.com>
> *To:* tself@hyperwrite.com; dita-help@lists.oasis-open.org
> *Sent:* Mon, 6 December, 2010 14:46:47
> *Subject:* RE: [dita-help] Help Features in DITA 1.3
>
> Hi all.
>
> I agree. The base topic types work fine for UA. We just need to tweak a
> few things to add some hooks for UA delivery. I agree with the community
> that DITA is getting a little complex.
>
> Regards.
>
> Chris Goolsby
> PTC
>
>
> -----Original Message-----
> From: Tony Self [mailto:tself@hyperwrite.com 
> <mailto:tself@hyperwrite.com>]
> Sent: Monday, December 06, 2010 1:33 AM
> To: dita-help@lists.oasis-open.org <mailto:dita-help@lists.oasis-open.org>
> Subject: [dita-help] Help Features in DITA 1.3
>
> Greetings colleagues
>
> Now that 1.2 has been released, we have to start thinking about 1.3. You
> will probably recall that the Help Subcommittee was established to make
> recommendations for 1.3; it wasn't anticipated that 1.3 would be so far
> away.
>
> So far, we have proposals for spec changes to better handle context
> hooks,
> and window definitions.
>
> We have discussed in the past the possibility of a specialisation for
> integrated or embedded user assistance content.
>
> There has been some negative feedback from the community about the
> perceived
> complexity of 1.2, with new information types, constrained versions of
> some
> types, and a (perceived) mushrooming in the number of elements.
>
> My feeling is that the context hook and window definitions should be
> built
> into the base content model. My feeling is that we should not have a
> specialised information type for UA, mainly because I don't think the
> community is demanding such a thing.
>
> What do you all think?
>
> Tony Self
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>  
>