dita — archive

[Su-Laine Yeo <syeo@justsystems.com>]

Michael's proposal makes a lot of sense, as there are definitely many cases in which you would not want to have an element type be presented to authors, but you would not actually mind if that element got into the document. XMetaL does conref validation and I'm told that Michael's proposal would not be a big deal for the XMetaL development team to support, however we'd like to hear from more CMS vendors in terms of whether their tools will be able to skip validation for weak constraints. It will be a problem if the authoring tool thinks a conref is valid but the CMS thinks it's invalid. Don, I agree that due diligence is warranted. To partly answer your question, I personally have very little bandwidth for the next couple of months to work on it. I'd like to add another concern about validation of strong constraints though: The purpose of defining what makes an conref invalid is to ensure that what gets put into a document via conref can be processed in a predictable way. The problem we have is that our DITA 1.2 definition of "what makes a conref invalid" is too broad, so it will produce a lot of false positives. So far I've found that DITA 1.0 and 1.1 implementers can get their head around the concept that you can't make a conref between different element types unless their specialization properties are such-and-such. However, implementers have a very difficult time getting their head around the idea that you can't conref between a map and a topic even if the source and target element names *and content models* are exactly the same. When source and target element types have identical content models, people expect to be able to conref between them, and if this fails they consider the case to be a false positive. Educating people helps them understand that they can't get what they expect, but it doesn't stop them from expecting it. I don't have a concrete suggestion for redefining "what makes an invalid conref" to allow conrefs between any two elements that have compatible content models. But if we can do it, and can do it in a way that tools can support, it would be a great improvement to the DITA standard. Regards, Su-Laine Su-Laine Yeo Interaction Design Specialist JustSystems Canada, Inc. Office: 778-327-6356 syeo@justsystems.com www.justsystems.com