RE: [dita] Why There are Constraints on Conref

["Ogden, Jeff" <jogden@ptc.com>]

Product Names aren't the same as "individual words" and so the
translation best practice doesn't really apply to the example given.

And guidelines and best practices are just that. The question that is
being asked here is will DITA 1.2 disallow a common practice that was
allowed and quite commonly used with DITA 1.0 and 1.1.  Thankfully the
answer is that DITA 1.2 doesn't make anything illegal that was legal in
DITA 1.0 or 1.1.  But if it had been the other way, then the existence
of guidelines and best practices wouldn't prevent it from being an
incompatible change that we'd have wanted to avoid. So it was a very
good question for Su-Laine to ask.

   -Jeff

> -----Original Message-----
> From: Andrzej Zydron [mailto:azydron@xml-intl.com]
> Sent: Saturday, September 26, 2009 1:58 PM
> To: Su-Laine Yeo
> Cc: ekimber; JoAnn Hackos; Michael Priestley; rob@ascan.ca; dita
> Subject: Re: [dita] Why There are Constraints on Conref
> 
> Hi Su-Laine,
> 
> The DITA Translation Sub Committee, chaired by JoAnn, has produced
> detailed guidelines and best practice documents on the use of conref,
> and one of the first rules is to never use this mechanism for
replacing
> individual words. JoAnn will be able to cite real world examples of
the
> type of disaster that this can cause.
> 
> Does no one take any notice of the output of the Translation Sub
> Committee? This is not the first time that I have come across this
> issue recently.
> 
> Best Regards,
> 
> AZ
> 
> Su-Laine Yeo wrote:
> > I'm having one of those, "this can't be right" moments. Either I've
> > completely misunderstood something or we have a problem.
> >
> > Consider this very common use of conref: You have a list of product
> > names, with each product name in a <ph> element. Your <ph> elements
> > that contain product names are all stored in a <topic> element
within
> > a product names file, which uses the ditabase DTD. With DITA 1.1 you
> > can conref those product names into any topic type.
> >
> > Say you have a task written in DITA 1.1 which includes a conref
> > pointing to a product name in the product names file. What is going
> to
> > happen when you upgrade your DTDs to DITA 1.2? If I understand the
> way
> > constraints on conref are supposed to work, that conref is going to
> be
> > considered invalid even though <ph> has exactly the same content
> model
> > in <task> as it does in <topic>. Is that correct?
> >
> > Regards,
> > Su-Laine
> >
> > Su-Laine Yeo
> > Interaction Design Specialist
> > JustSystems Canada, Inc.
> > Office: 778-327-6356
> > syeo@justsystems.com
> > www.justsystems.com
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: ekimber [mailto:ekimber@reallysi.com]
> > Sent: Friday, September 25, 2009 3:53 PM
> > To: JoAnn Hackos; Su-Laine Yeo; Michael Priestley; rob@ascan.ca
> > Cc: dita; Ogden, Jeff
> > Subject: Re: [dita] Why There are Constraints on Conref
> >
> > On 9/25/09 5:31 PM, "JoAnn Hackos" <joann.hackos@comtech-serv.com>
> > wrote:
> >
> >
> >> Are we clear in saying that one cannot conref between Task and
> >> General Task at all? or only from Task to General Task? Is it
> >> possible to
> >>
> > conref
> >
> >> from General Task to Task?
> >>
> >> From loose to more constrained, will the conref work?
> >> So can I conref a prereq from General Task to a prereq to Task but
> >> not vice versa?
> >>
> >> But, I cannot conref a <step> from Task to General Task even though
> >>
> > they
> >
> >> are in both models?
> >>
> >> Would someone please state all the use cases simply? I'm trying to
> be
> >> clear in writing the arch spec and the feature description and I'm
> >>
> > still
> >
> >> confused by all the rhetoric being flung around.
> >>
> >
> > Give a strict task and a general task:
> >
> > 1. Can conref elements from strict task into general task 2. Cannot
> > conref elements from general task into strict task
> >
> > That is, you can *always* conref more-constrained elements into
> > less-constrained elements. You can *never* conref less-constrained
> > elements into more-constrained elements.
> >
> > Cheers,
> >
> > Eliot
> > ----
> > Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> > email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> > office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the
> > Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com
> > <http://www.reallysi.com>  | http://blog.reallysi.com
> > <http://blog.reallysi.com> | www.rsuitecms.com
> > <http://www.rsuitecms.com>
> >
> >
> >
---------------------------------------------------------------------
> > 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
> >
> >
> 
> --
> email - azydron@xml-intl.com
> smail - c/o Mr. A.Zydron
> 	PO Box 2167
>         Gerrards Cross
>         Bucks SL9 8XF
> 	United Kingdom
> Mobile +(44) 7966 477 181
> FAX    +(44) 1753 480 465
> www - http://www.xml-intl.com
> 
> This message contains confidential information and is intended only
for
> the individual named.  If you are not the named addressee you may not
> disseminate, distribute or copy this e-mail.  Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses.  The sender therefore does not
> accept liability for any errors or omissions in the contents of this
> message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version. Unless
> explicitly stated otherwise this message is provided for informational
> purposes only and should not be construed as a solicitation or offer.
>