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


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]
Sent: Monday, December 06, 2010 1:33 AM
To: 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

 



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