[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: conref and xinclude [was: [dita] Meeting Minutes 6/22/2004]
At 15:34 2004-06-24 -0700, Larsen, Seraphim L wrote: >Meeting Minutes 6/22/2004 -- DITA Technical Committee > > - Shawn: Some things appear to be non-standard XML, > such as the conref feature. How do we handle > things like this? > - Michael: xinclude doesn't do the things we > need it to do, so we invented conref instead. > But it can be processed by XSTL so it's not > really nonstandard XML. > > - Shawn: So, is it an issue or not? > > - Paul Grosso: He's talked with Eliot about > this. He thinks we should consider using > xinclude in a future release, because it's > been widely adopted already. > > - Eliot: Processing semantics associated with > conref are partly semantic and partly > processing rules. Need to separate them out. > > - Discussion ensued... > > - Don: We're running out of time, let's take > this discussion to the list. Eliot's 2004 June 22 posting [1] is an excellent discussion that has helped me understand this issue better. (And I also chatted on the phone with Eliot about it further.) The bottom line for me is that what DITA is doing is neither "conref" in the SGML sense nor XInclude, though it borrows some semantics from each of those. More specifically, XInclude as it is now defined does not address DITA's needs. So our choice is either to use xinclude and then layer on top of that the extra needed semantics or use something of our own invention (as we are doing now with DITA's "conref") and layer on top the needed semantics. And the current "conref" approach actually requires less added semantics, since most of Eliot's requirements 1 and 2 (in his posting) are already addressed by the current approach but would not be addressed by xinclude. However, this does leave us with a bit of an issue: how to explain why we are using "conref" instead of XInclude. As already witnessed, we can expect the question to arise. I think it is perhaps unfortunate that DITA chose the term "conref" since that harkens back to SGML (and yet even SGML's conref wouldn't sufficiently address all of DITA's requirements). I think we need to consider what we can do in 1.0 to address this issue head-on. I don't know to what extent we can remove the "conref" term from DITA, but at the least we need to make obvious explanations in the spec (and maybe add a FAQ) explaining that what DITA is doing isn't contrary to XML, but is rather a level of processing that of necessity goes beyond currently defined basic XML processing. In a post-1.0 time frame, we may also want to work with the W3C to augment XInclude to address more of DITA's needs (since I think these needs are not specific to DITA). I'm not sure what kind of reception we'd get, but being the chair of the W3C working group responsible for XInclude, I could at least ensure our ideas get a hearing. paul [1] http://lists.oasis-open.org/archives/dita/200406/msg00038.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]