OASIS Darwin Information Typing Architecture (DITA) TC

The recent discussion around ditabase and the various task configurations
suggests that we need more public discussion of why DITA imposes what may at
first appear to be draconian constraints on conref.

I think it's important to understand that there are several different use
cases in which constraints are or are not important, but that, overall, the
constraints are necessary in order for DITA content to be both interoperable
and interchangeable.

In the case of processing, for the most part, conref constraints are not
relevant, because most, if not all processors, will be able to process any
valid DITA elements, in any combination, constrained or not. That means, for
example, that a constrained topic referencing content from an unconstrained
topic wouldn't normally cause problems for processors. I suspect this is the
way most DITA users think about the implications of conref constraints.

[Note: This is not the same as allowing specialized elements to conref
unspecialized content--that's a different issue and allowing that *would*
break processors, because specializations may establish specific contracts
for what they can contain and how they need to be processed. The textbook
example is 

Isn't the real problem here the inability to include the same DITA topic
type more than once with different constraints (or different domains or
different topic nesting) in a Ditabase?  And isn't that limitation due
to limitations about what can be done using DTDs?  Would the limitation
go away if we could use XSDs rather than DTDs? Wouldn't removing the
limitation be a better long term solution for this issue?  It seems sad
to have to live with the limitation if a better solution exists using
XSDs.

I'm pretty sure that no matter what we do now in terms of what we
include in DITA 1.2 and how much we try to explain this, that these
issues are going to cause confusion for a lot of people as long as the
limitation with Ditabases remains.

   -Jeff

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Thursday, September 24, 2009 9:26 AM
> To: dita
> Subject: [dita] Why There are Constraints on Conref
> 
> The recent discussion around ditabase and the various task
> configurations
> suggests that we need more public discussion of why DITA imposes what
> may at
> first appear to be draconian constraints on conref.
> 
> I think it's important to understand that there are several different
> use
> cases in which constraints are or are not important, but that,
overall,
> the
> constraints are necessary in order for DITA content to be both
> interoperable
> and interchangeable.
> 
> In the case of processing, for the most part, conref constraints are
> not
> relevant, because most, if not all processors, will be able to process
> any
> valid DITA elements, in any combination, constrained or not. That
means,
> for
> example, that a constrained topic referencing content from an
> unconstrained
> topic wouldn't normally cause problems for processors. I suspect this
> is the
> way most DITA users think about the implications of conref
constraints.
> 
> [Note: This is not the same as allowing specialized elements to conref
> unspecialized content--that's a different issue and allowing that
> *would*
> break processors, because specializations may establish specific
> contracts
> for what they can contain and how they need to be processed. The
> textbook
> example is 

On 9/24/09 9:09 AM, "Ogden, Jeff" 

Constraints potentially offer a unique opportunity for managing different
business rules across an enterprise or industry. In my opinion, a task is a
task - the current proposal seems to change that. Again in my opinion, this
is fundamental to exchange of information across groups. What we are
otherwise talking about goes well beyond the simple task example provided in
DITA 1.2. Architects could very well try to take advantage of the constraint
mechanism as a means of improving the usability of the authoring templates.
In so doing, under the current proposal, they would be rendering their
content unusable outside of their environment.

If one group imposes business rules that are stricter than another, that
group must decide how it wants to reuse content from the other group.
Ideally, the two groups can reach a mutual understanding and twin their DTDs
to match. In reality, the business rules may be different for reasons beyond
the control of one group or another.

The worst possible result would be that the first group must rewrite and
manage the content provided by the second group because it was incompatible.
There are inevitably situations where this will occur - but we have an
opportunity to minimize the frequency of these situations.

The opportunities for reuse between constrained and unconstrained content is
significant. Unlike examples cited where reference content is reused in task
content, the two variations of constrained and unconstrained information are
semantically similar. The failure or fall back mode of processors to handle
unconstrained content reuse within constrained topics should not be the same
as reusing dissimilar content types.

I believe that authors and publishers should be alerted to instances where
the reused content fails to adhere to the stricter version of the model but
they should not be prevented from using it.

What if we introduced a sort of name space mechanism to the conref that
could be used by processors to validate the content against the proper
model? This would only work between two topics of the same document type
(one loose and the other strict).

Cheers,

Rob Hanna

My primary concern is distinguishing
cases that will break processing. Bringing in other content into a namespace
would almost certainly break processing, since there are no namespaces
currently in DITA, and no tools would know what to do with it. 

If we bring in content via conref, I
think it has to be normal, un-namespaced DITA. Otherwise processes that
don't know what it is (ie all existing processes) will either ignore the
content (effectively deleting the reused content), or throw errors and
break.

I think the first question is how big
is the problem we're actually talking about:
- how common will it be for two groups
to have different rules around what goes in a task, and still need to share
content (in both directions)?
- for those different-rules-but-need-to-share
groups, how common will it be for them to want to ignore their own rules
when they are reusing? IE, enforce rules when their authors create content,
but ignore the rules when their authors conref others' content?

You say the worst case is that one group
might need to rewrite content; I actually think that may be quite normal,
and not a worst case at all. Think of an actual example:

- group L has a bunch of loose tasks;
they follow a best practice of conreffing from a loose task type file full
of common content
- group S has a bunch of strict tasks,
and some similar common content, stored in a strict task type file
- the groups agree to merge their common
content, so they can share reuse
- they identify the elements in group
L's ditabase files that are of interest to both teams, and move them into
a new ditabase file that enforces the strict task type
- now group L has two common-content
task files: one that uses the loose task type, with elements that only
they use, and one that uses the strict task type, which both can use

Because group L moved the cross-group
content into the stricter doctype, both groups now have a guaranty that
nothing will go into that file which could break the content rules and
processing expectations of either group.

So that's how it would work the current
rules. I don't think that's the end of the world. Two groups that are conreffing
content probably need to have some level of coordination anyway - it's
not like map-based reuse, where you can just point at a topic; you're pointing
at an element ID, and hoping it's still there tomorrow.

Michael Priestley, Senior Technical
Staff Member (STSM)

Lead IBM DITA Architect

mpriestl@ca.ibm.com

http://dita.xml.org/blog/25





From:
"Rob Hanna" <rob@ascan.ca>

To:
"'ekimber'" <ekimber@reallysi.com>,
"'Ogden, Jeff'" <jogden@ptc.com>, "'dita'" <dita@lists.oasis-open.org>

Date:
09/24/2009 04:16 PM

Subject:
RE: [dita] Why There are Constraints
on Conref





Constraints potentially offer a unique opportunity
for managing different

business rules across an enterprise or industry. In my opinion, a task
is a

task - the current proposal seems to change that. Again in my opinion,
this

is fundamental to exchange of information across groups. What we are

otherwise talking about goes well beyond the simple task example provided
in

DITA 1.2. Architects could very well try to take advantage of the constraint

mechanism as a means of improving the usability of the authoring templates.

In so doing, under the current proposal, they would be rendering their

content unusable outside of their environment.


If one group imposes business rules that are stricter than another, that

group must decide how it wants to reuse content from the other group.

Ideally, the two groups can reach a mutual understanding and twin their
DTDs

to match. In reality, the business rules may be different for reasons beyond

the control of one group or another.


The worst possible result would be that the first group must rewrite and

manage the content provided by the second group because it was incompatible.

There are inevitably situations where this will occur - but we have an

opportunity to minimize the frequency of these situations.


The opportunities for reuse between constrained and unconstrained content
is

significant. Unlike examples cited where reference content is reused in
task

content, the two variations of constrained and unconstrained information
are

semantically similar. The failure or fall back mode of processors to handle

unconstrained content reuse within constrained topics should not be the
same

as reusing dissimilar content types.


I believe that authors and publishers should be alerted to instances where

the reused content fails to adhere to the stricter version of the model
but

they should not be prevented from using it.


What if we introduced a sort of name space mechanism to the conref that

could be used by processors to validate the content against the proper

model? This would only work between two topics of the same document type

(one loose and the other strict).


Cheers,


Rob Hanna



---------------------------------------------------------------------

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

Many
interesting issues are being raised, and I just want to address one of the memes
before it spreads:



“Architects could very well try to take advantage of
the constraint

mechanism as a means of improving the usability of the authoring templates.

In so doing, under the current proposal, they would be rendering their

content unusable outside of their environment.”



As
I understand the spec, architects who add constraints do not have to worry
about making their content unusable to others. You can conref more-constrained
content into less-constrained document types.



Su-Laine





Su-Laine Yeo

Interaction Design Specialist 

JustSystems Canada, Inc.

Office: 778-327-6356

syeo@justsystems.com

www.justsystems.com 









From: Michael Priestley
[mailto:mpriestl@ca.ibm.com]

Sent: Thursday, September 24, 2009 2:54 PM

To: rob@ascan.ca

Cc: 'dita'; 'ekimber'; 'Ogden, Jeff'

Subject: RE: [dita] Why There are Constraints on Conref







My primary
concern is distinguishing cases that will break processing. Bringing in other
content into a namespace would almost certainly break processing, since there
are no namespaces currently in DITA, and no tools would know what to do with
it. 


If we bring in
content via conref, I think it has to be normal, un-namespaced DITA. Otherwise
processes that don't know what it is (ie all existing processes) will either
ignore the content (effectively deleting the reused content), or throw errors
and break.


I think the
first question is how big is the problem we're actually talking about:

- how common
will it be for two groups to have different rules around what goes in a task, and
still need to share content (in both directions)?

- for those
different-rules-but-need-to-share groups, how common will it be for them to
want to ignore their own rules when they are reusing? IE, enforce rules when
their authors create content, but ignore the rules when their authors conref
others' content?


You say the
worst case is that one group might need to rewrite content; I actually think
that may be quite normal, and not a worst case at all. Think of an actual
example:


- group L has a
bunch of loose tasks; they follow a best practice of conreffing from a loose
task type file full of common content

- group S has a
bunch of strict tasks, and some similar common content, stored in a strict task
type file

- the groups
agree to merge their common content, so they can share reuse

- they identify
the elements in group L's ditabase files that are of interest to both teams,
and move them into a new ditabase file that enforces the strict task type

- now group L
has two common-content task files: one that uses the loose task type, with
elements that only they use, and one that uses the strict task type, which both
can use


Because group L
moved the cross-group content into the stricter doctype, both groups now have a
guaranty that nothing will go into that file which could break the content
rules and processing expectations of either group.


So that's how
it would work the current rules. I don't think that's the end of the world. Two
groups that are conreffing content probably need to have some level of
coordination anyway - it's not like map-based reuse, where you can just point
at a topic; you're pointing at an element ID, and hoping it's still there
tomorrow.


Michael
Priestley, Senior Technical Staff Member (STSM)

Lead IBM DITA Architect

mpriestl@ca.ibm.com

http://dita.xml.org/blog/25





 

  

  
From: 
  
  

  
"Rob
  Hanna" <rob@ascan.ca> 
  
 
 

  

  
To: 
  
  

  
"'ekimber'"
  <ekimber@reallysi.com>, "'Ogden, Jeff'"
  <jogden@ptc.com>, "'dita'" <dita@lists.oasis-open.org>
  
  
 
 

  

  
Date: 
  
  

  
09/24/2009
  04:16 PM 
  
 
 

  

  
Subject: 
  
  

  
RE:
  [dita] Why There are Constraints on Conref
  
 














Constraints potentially offer a unique
opportunity for managing different

business rules across an enterprise or industry. In my opinion, a task is a

task - the current proposal seems to change that. Again in my opinion, this

is fundamental to exchange of information across groups. What we are

otherwise talking about goes well beyond the simple task example provided
in

DITA 1.2. Architects could very well try to take advantage of the
constraint

mechanism as a means of improving the usability of the authoring templates.

In so doing, under the current proposal, they would be rendering their

content unusable outside of their environment.


If one group imposes business rules that are stricter than another, that

group must decide how it wants to reuse content from the other group.

Ideally, the two groups can reach a mutual understanding and twin their
DTDs

to match. In reality, the business rules may be different for reasons
beyond

the control of one group or another.


The worst possible result would be that the first group must rewrite and

manage the content provided by the second group because it was
incompatible.

There are inevitably situations where this will occur - but we have an

opportunity to minimize the frequency of these situations.


The opportunities for reuse between constrained and unconstrained content
is

significant. Unlike examples cited where reference content is reused in
task

content, the two variations of constrained and unconstrained information
are

semantically similar. The failure or fall back mode of processors to handle

unconstrained content reuse within constrained topics should not be the
same

as reusing dissimilar content types.


I believe that authors and publishers should be alerted to instances where

the reused content fails to adhere to the stricter version of the model but

they should not be prevented from using it.


What if we introduced a sort of name space mechanism to the conref that

could be used by processors to validate the content against the proper

model? This would only work between two topics of the same document type

(one loose and the other strict).


Cheers,


Rob Hanna



---------------------------------------------------------------------

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 

On 9/24/09 4:55 PM, "Su-Laine Yeo" 

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 

On 9/25/09 5:31 PM, "JoAnn Hackos" 

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 

Hi Andrzej,

We do take notice, and review it, and
send you comments, which you incorporate. See the section on conreffing
proper nouns. Nothing that Su-Laine describes contradicts those practices,
which are allowable with a bunch of caveats, and I'm concerned that you
think it does.

Michael Priestley, Senior Technical
Staff Member (STSM)

Lead IBM DITA Architect

mpriestl@ca.ibm.com

http://dita.xml.org/blog/25





From:
Andrzej Zydron <azydron@xml-intl.com>

To:
Su-Laine Yeo <su-laine.yeo@justsystems.com>

Cc:
ekimber <ekimber@reallysi.com>,
JoAnn Hackos <joann.hackos@comtech-serv.com>, Michael Priestley/Toronto/IBM@IBMCA,
rob@ascan.ca, dita <dita@lists.oasis-open.org>

Date:
09/26/2009 01:55 PM

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
                                                
                                                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.



[attachment "azydron.vcf" deleted by Michael Priestley/Toronto/IBM]
---------------------------------------------------------------------

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

I think Andrej's valid complaint 
is that some of us (I for one) had not read and reflected on those detailed 
guidelines. I hadn't because I'm not 
pressingly concerned with translation. My mistake. 
 
Use of conref rather than entity 
references for 'variables' such as product names is an obvious desideratum. 
There may be some confusion and even outright consternation among users if it's 
a bad idea.
 
These guidelines are obviously 
of general import, not limited to translation. I just looked for them and 
couldn't find them. Am I overlooking something obvious, or could guidelines (findings, recommendations, etc.) of subcommittees be 
made more easily accessible to people not on a given 
subcommittee
 
    
/Bruce?



  

  

  From: Michael Priestley 
  [mailto:mpriestl@ca.ibm.com]
Sent: Monday, September 28, 2009 11:52 
  AM
To: Andrzej Zydron
Cc: dita; ekimber; JoAnn Hackos; 
  rob@ascan.ca; Su-Laine Yeo
Subject: Re: [dita] Why There are 
  Constraints on Conref


  

Hi Andrzej,

We do take notice, and review it, and send you 
  comments, which you incorporate. See the section on conreffing proper nouns. 
  Nothing that Su-Laine describes contradicts those practices, which are 
  allowable with a bunch of caveats, and I'm concerned that you think it 
  does.

Michael Priestley, Senior 
  Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



  

    

    

      
From: 
      
Andrzej Zydron 
        <azydron@xml-intl.com> 
    

      
To: 
      
Su-Laine Yeo 
        <su-laine.yeo@justsystems.com> 
    

      
Cc: 
      
ekimber <ekimber@reallysi.com>, 
        JoAnn Hackos <joann.hackos@comtech-serv.com>, Michael 
        Priestley/Toronto/IBM@IBMCA, rob@ascan.ca, dita 
        <dita@lists.oasis-open.org> 
    

      
Date: 
      
09/26/2009 01:55 PM 
    

      
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.


[attachment "azydron.vcf" deleted by Michael 
  Priestley/Toronto/IBM] 
  ---------------------------------------------------------------------
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 

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
                                                
                                                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 

Su-Laine is asking the same question I'm concerned about. We need a simple
answer. I'm having a hard time with the arcane details.

Is DITA 1.2 going to mess up all the conrefs we have set up in DITA 1.1
between ditabase or topic and Task?

JoAnn


On 9/25/09 8:24 PM, "Su-Laine Yeo" 

On 9/27/09 9:55 AM, "Joann Hackos" 

Hi JoAnn,

I think Eliot already answered your correctly, but you asked for a simple
answer to this question:
> > Is DITA 1.2 going to mess up all the conrefs we have set up in DITA 1.1
> > between ditabase or topic and Task?

The simple answer is "No."

Trying to explain things as simply as I can - the only time that
constraints affect conref is:
1) The conref goes between files with two different document types
2) The files include a matching topic type or domain (for example, both
include task or both include the highlighting domain)
3) One of the common modules has a constraint (such as the strictTask if
both use task, or a constraint to remove bold from the highlight domian)
4) The element that uses conref is in the file with the constraint -
meaning that the file trying to pull content removes elements, but the file
*with* the content does not

I'm guessing that still isn't perfectly clear, because this is never going
to be simple to explain architecturally, just like the class attribute and
specialization take a while to get your head around when first introduced.
Hopefully it helps though. It also shows that Su-Laine's example will
continue to work. If you store common items in a topic, you will still be
able to pull them into a strict task or a general task, and vice versa. The
original topic does not include the task module, so any constraint on the
task module is irrelevant for the purposes of conref.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

ekimber 

No it isn't (going to mess up all the conrefs we have set up in DITA 1.1
between ditabase or topic and Task).

None of the conref compatibility issues are really new to DITA 1.2, we'e
had the same sorts of issues related to domains all along. It is just
that the introduction of General and constrained Tasks in DITA 1.2 has
raised the visibility of the issue.

We do need to fix ditabase so it includes constrained Task rather than
general Task or we will have problems, but I think we've agreed to make
that fix.

    -Jeff

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Joann Hackos [mailto:joann.hackos@comtech-serv.com]
> Sent: Sunday, September 27, 2009 10:56 AM
> To: Su-Laine Yeo; Eliot Kimber; Michael Priestley; rob@ascan.ca
> Cc: DITA TC
> Subject: Re: [dita] Why There are Constraints on Conref
> 
> Su-Laine is asking the same question I'm concerned about. We need a
> simple
> answer. I'm having a hard time with the arcane details.
> 
> Is DITA 1.2 going to mess up all the conrefs we have set up in DITA
1.1
> between ditabase or topic and Task?
> 
> JoAnn
> 
> 
> On 9/25/09 8:24 PM, "Su-Laine Yeo" 

On 9/25/09 5:53 PM, "ekimber"