Thanks for getting back to me so quickly - Hussein, you are wonderful as always - and with a workaround.
I did see that section of the spec. When I read the phrase: "For each vocabulary module in the referenced document, the referencing document qualifies the common module with a subset of the constraints in the referenced document." I assumed that this should mean that between two documents any vocabulary that the two have in common (i.e. the most restrictive constraint) is used. That should mean that any vocabulary that concept and reference topics have in common should be conref-able. (which would make sense). I thought that was further borne out in the examples in the section, which never use topic type as a qualifier, which they definitely _should_ if they intended such a drastic change. Also, it says in the generalization and constraints section that a generalization processor "Looks for the first vocabulary module that is both present in the target document type and that has a subset of the constraints in the document instance" which also implies what I said above. So I think you should follow your first instinct, which was that it made no sense the other way and change your implementation. I will use the workaround however, with thanks. -----Original Message----- From: Hussein Shafie [mailto:[email protected]] Sent: Wednesday, March 23, 2011 3:16 PM To: Tyrin Avery Cc: '[email protected]' Subject: Re: [XXE] Can't retransclude reference On 03/23/2011 07:23 PM, Tyrin Avery wrote: > > I'm using XMLMind Professional 4.8 > > > > When I try to retransclude a reference that I've had in the doc for > over a year I get the following error: > > > > Inclusion Error > > file:/C:/DemandwareStudio/workspace/documentation/branches/maintenance.2.11.1/doc/DITA/source/ditamap/SiteDevelopment/Supporteddatatypes.dita::: > cannot fetch included nodes: the list of domains of the referenced > document "(topic reference) (topic hi-d) (topic ut-d) (topic indexing-d) > (topic hazard-d) (topic abbrev-d) (topic pr-d) (topic sw-d) (topic > ui-d)" must be equal or must be a subset of the list of domains of the > referencing document "(topic concept) (topic hi-d) (topic ut-d) (topic > indexing-d) (topic hazard-d) (topic abbrev-d) (topic pr-d) (topic sw-d) > (topic ui-d)" > In plain English, this means: you cannot include in a <concept> topic, a <table> element coming from a <reference> topic. > file:/C:/DemandwareStudio/workspace/documentation/branches/maintenance.2.11.1/doc/DITA/source/ditamap/SiteDevelopment/Supporteddatatypes.dita::: > document not fully processed after 3 iterations > > > > This error doesn't make any sense. The only difference in constraints > between the two topics is that one is a concept and one is a reference > type. They both use the <table> element. I've checked the DITA 1.2 spec, > and as far as I can tell, this should be allowed. Please tell us where you see this. We have very carefully implemented the following part of the spec: Excerpts from http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/constraintsGeneralize..html#constraintsGeneralize --- Conref compatibility with constraints To determine compatibility between two document instances, a conref processor can check the @domains attribute to confirm that * The referencing document has a superset of the vocabulary modules in the referenced document. * For each vocabulary module in the referenced document, the referencing document qualifies the common module with a subset of the constraints in the referenced document. Some examples .... --- > At the very least, I'd expect this to be backward-compatible, Yes, this used to work with XMLmind XML Editor v4.7/DITA 1.1 because the DITA 1.1 DTD specified just the following domains for both <concept> and <reference>: --- (topic hi-d) (topic ut-d) (topic indexing-d) (topic pr-d) (topic sw-d) (topic ui-d) --- But now DITA 1.2 specifies different, more complex, domains for <concept> and <reference>. > since this is an old conref and > hasn't changed. I'm pretty sure this is a bug in XMLMind. I'm sorry but this is *unfortunately* not a bug in XMLmind XML Editor. We would really like this to be a bug, because this part of the spec (checking domains instead of leveraging the DTD or schema) indeed does not make sense. Because we have expected this to happen, we have implemented a way to bypass this check. You'll have to add the following system property to the script used to start XMLmind XML Editor (bin/xxe Unix shell script OR bin/xxe.bat OR bin/xxe.jstart if you use bin/xxe.exe): -DXXE_LENIENT_CONREF=1 (We forgot to document this system property.) This e-mail message and all attachments transmitted with it may contain privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message, all attachments and all copies and backups thereof. -- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
