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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] Repeated conrefs


This message has been in my drafts folder forever. Sorry. You'll have to read from the bottom to get context.
 
  1. I do not think that your first answer is consistent with the DITA spec. When NOT using conref, IDs for topic content must be unique within the topic. My question was about conref’ing the same topic content element into the same topic twice. I believe that this should be disallowed or a mechanism should be provided for overriding the ID attribute.
  2. The question about conref-fing topics twice was not intended to be an implementation question: If it is disallowed then the DITA specification should be explicit about that. But why would conreffing an element twice be allowed but a topic twice is disallowed?
  3. If DITA disallows recursive conrefs then shouldn’t the DITA spec says so?

 

I’m therefore proposing three changes to the DITA specification.

 


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, October 11, 2005 3:36 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Repeated conrefs

 


Comments below...

Michael Priestley
IBM DITA Architect
SWG Classification Schema PDT Lead
mpriestl@ca.ibm.com


"Paul Prescod" <paul.prescod@blastradius.com> wrote on 10/06/2005 07:50:36 AM:

> By definition, every element that is conrefed has an “id” attribute.
> Is it therefore invalid to conref the same element into the same
> topic twice?


It is still valid. The id on most elements is not constrained to be unique, precisely to allow this as a valid case.

>And to conref the same topic into a parent topic twice?

This is not so valid. Topic-level elements must have unique ids. If the same topic gets conref'd into a document in multiple places, this does produce an error once the resolved document is parsed, and the conref processor doesn't currently check for that.


> Is it legal for an element with a DITA conref to reference another
> element with a conref? If so, shouldn’t DITA disallow mutually
> recursive conrefs?


It should, it's just an edge case that is expensive to check for, so I don't know of any process that currently does.

>  
> And as an implementation question: how many validating conref
> processors are known to exist and to support DITA semantics
> (including specialization, ID, filtering) explicitly?


The DITA Open Toolkit contains a specialization-aware domain-checking conref transform. I believe filtering is done in a separate step.

>  
>  Paul Prescod
>  



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