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] 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"                                                 
             al.com>                                                    To 
                                       "Grosso, Paul" <pgrosso@ptc.com>,   
             04/17/2007 12:04          <dita@lists.oasis-open.org>         
             PM                                                         cc 
                                       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

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).


> -----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]