OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-help message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I guess I'm thinking of some structure that hangs off of the map, like 
the keydef feature (or subjectScheme?) .. where you define the 
windowdefkey once, and reference the key when needed. This key 
definition could allow for multiple definitions that are used for 
different output types.

I dunno .. just thinking.

This structure could also be used for images and tables. It lets you 
keep the values available for authors to set and manage, but separates 
them from the immediate vicinity of the content (again .. I should 
locate the window definition spec).

Crazy, perhaps?

...scott



Tony Self wrote:
> Hi Scott
>
>   
>>> some sort of key that maps to the actual window definition elsewhere<<
>>>       
>
> But where is "elsewhere"? Putting the definitions in the ditaval would change the role of ditaval. (Maybe that's not a bad thing, though.) In the publishing engine configuration files? 
>
> If the information is going to be stored somewhere (and isn't ditaval now part of the OASIS DITA spec?), then somewhere or other a good number of window properties have to be stored. From the point of view of complexity, does it matter whether this complexity is in the map or the ditaval or the publishing config file?
>
> Tony Self
>
>
> -----Original Message-----
> From: Scott Prentice [mailto:sp10@leximation.com] 
> Sent: Wednesday, 8 December 2010 10:03 AM
> To: tself@hyperwrite.com
> Cc: dita-help@lists.oasis-open.org
> Subject: Re: [dita-help] Help Features in DITA 1.3
>
> 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
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> 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 
>
>
>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]