Re: [dita] 12005 supports 12052--adding DITAArchVersion to the ditaelement

[Dana Spradley <dana.spradley@oracle.com>]

Isn't dita the only element that should be reference by name - since it isn't specializable via a class attribute?

And couldn't its topic children be in different languages? Does the dita element have any strings in languages of its own?

I'd expect you'd process dita children using an xsl:if test="dita", xsl:for-each select="dita/*"..., or something like that.

--Dana

Grosso, Paul wrote:

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Friday, 2007 April 20 13:33
To: Yas Etessam
Cc: dita@lists.oasis-open.org; Grosso, Paul
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.
    

That sounds like a good idea to me.

  

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.
    

I agree with adding xml:lang (and xml:base if we do that)
to the dita element too.

  

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.
    

I agree with just about everything Robert says here--both his
arguments and conclusions.

paul