[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] 12005 supports 12052--adding DITAArchVersion to the dita element
Throwing in my own couple of cents on these issues - I know that there are points in DITA processing when I have to know about the <dita> element. This happens any time I must check one specific item in a file. For example, using () to shorten the class attribute syntax, I have to look up domains with either /(topic)/@domains or /dita/(topic)[1]/@domains. Similarly, to pull a title from a file, I have to pull from both /(topic)/(title) and /dita/(topic)[1]/(title). I've found it odd that <dita> is the only element in any of my stylesheets which is referenced by name, so adding @class does make some sense. I'm really neutral on whether to add it. However, if we add class, I'd favor making it FIXED with its own value (something like dita/dita), so that it's clearly not a topic and not specializable. On the separate issue of DITAArchVersion - I have no objection to adding that. If buy Paul's arguments about being able to easily identify the document from this root element. Now to toss oil on the fire, I personally think that xml:lang should also be available on the <dita> element. I have actually heard this request from users, who think it strange to set xml:lang on each of the topic children of <dita>. This is a standard XML attribute, so adding it does not make the element more meaningful within the DITA architecture. However, given that this is such a minor issue, if there are objections I will not pursue it. Note that the same arguments could be made for xml:base if that proposal is accepted and completed for DITA 1.2. In my view, these attributes do not do anything more than indicate that "This is a DITA element" or "This is XML". So, I do not think there are any concerns with being on a slippery slope. We only step on that slope if we add meaningful DITA-specific attributes such as @platform or @props. I have not heard anybody seriously suggest adding these. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 "Yas Etessam" <yas.etessam@xmet al.com> To "Grosso, Paul" <pgrosso@ptc.com>, 04/17/2007 12:04 <dita@lists.oasis-open.org> PM cc Subject RE: [dita] 12005 supports 12052--adding DITAArchVersion to the dita element Hi Paul, Your observations are correct. XML editors currently need to use a combination of topic-level atts and the <dita> element to identify DITA documents. Adding DITAArchVersion to the <dita> element would slightly simplify the process of identifying DITA documents. Although, there are clearly already workarounds to this issue if you check the topic-level atts. During our original pass on the feature set, we supported 12052 as a simple change. We will continue to support it. I don't see how if will have any major architectural effects (like the 12051 proposal). Yas > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Tuesday, April 17, 2007 9:23 AM > To: dita@lists.oasis-open.org > Subject: [dita] 12005 supports 12052--adding DITAArchVersion > to the dita element > > In our short list, I see: > > 12005 Recognizing DITA Documents > > I read the thread referenced there (it is broken into two > parts in the archive, so you need to look for two starts to > the thread). > > It sounds very much like Paul Prescod was trying to say the > same thing I was saying in my argument for adding > DITAArchVersion to the dita element. So two DITA editor > vendors both seem to see a similar need. > > ErikH answers PaulP that the DITAArchVersion attribute should > give him what he wants. Erik goes on to say (about DITA > document elements that have the DITAArchVersion attribute): > > The sole exception is the <dita> element, which has an odd > role because it has no semantics and merely contains a list > of topics. > Because the <dita> element cannot be specialized, it's name > cannot be changed. If someone wanted to make the case that, > for convenience and consistency, the <dita> element should > also take the [DITAArchVersion] attribute, I could buy that. > > I understand Eliot's points about the fact that you cannot > infer a document's doctype from its document element, but I > don't think that is the issue here. Besides, Eliot has voted > for 12052 (adding the DITAArchVersion attribute to the dita element). > > And reading the thread for 12005, it doesn't sound like PaulP > changed his desire for a DITAArchVersion attribute on the > dita element. > > So reading 12005, I see even more support for 12052. > > paul >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]