Re: [dita] ditaval should not be normative in 1.1

[Michael Priestley <mpriestl@ca.ibm.com>]

It was part of feature 20, "extensible
metadata attributes". 

Taking a look through past minutes I
couldn't find any discussion of it being normative or not. My assumption
would be that, as part of an approved proposal, it's normative by default.
Is there a case for making it non-normative?

The ditaval format was non-normative
in 1.0 because we didn't have time to discuss it or agree on a format.
We spent quite a lot of time on it this time around, as I'm sure you recall
- it would certainly seem odd to me to have spent that much time on the
format if it's not normative.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Grosso, Paul" <pgrosso@ptc.com>

12/08/2006 01:51 PM

To	<dita@lists.oasis-open.org>
cc	"Ogden, Jeff" <jogden@ptc.com>
Subject	[dita] ditaval should not be normative in 1.1

> -----Original Message-----
> From: mpriestl@ca.ibm.com [mailto:mpriestl@ca.ibm.com] 
> Sent: Tuesday, 2006 November 28 09:53
> To: dita@lists.oasis-open.org
> Subject: [dita] Groups - DITA Arch spec 1.1 - work in 
> progress (ditaspec.pdf) uploaded
> 
> reorganized to make behavior descriptions (eg conref and 
> profiling) more
> prominent - per comments from jeff ogden
> added dtd/schema module usage summaries (from robert and eric)
> added metadata inheritance/resolution between maps/topics 
> (from robert)
> added conref attribute override behavior
> added map inheritance with relationship tables
> incorporated second round of jeff ogden comments

I also see the following note in this draft (under
Conditional processing profiles):

 jeff ogden: wanted this in a new section of the spec
 rather than under common attributes. now done. Also,
 for the record: this is part of the spec. The ditaval
 format was not normative in 1.0, it is normative in 1.1.
 There was some old wording from 1.0 earlier that confused
 the issue, I've removed it.

Do we have any record of deciding to make the ditaval 
stuff normative in 1.1?

I don't remember deciding to do so.  I've always thought
that the ditaval stuff is too implementation specific to
be part of the DITA spec--the spec should be documenting
the standard, not the Toolkit's implementation--and I 
certainly think making the ditaval stuff normative in a 
point release is inappropriate.

The consensus at Arbortext is that is isn't a good idea 
to include ditaval as part of the DITA 1.1 standard.

1) We think the DITA Standard needs to make a clear distinction 
about what the Standard requires and what is suggested, but not 
necessarily required, in terms of implementation.  We don't think
the 1.0 Standard does a good job of making that distinction clear. 
We think DITA 1.1 will be somewhat better in this regard, but still 
could be improved further.  We think including ditaval as part of
the 1.1 Standard adds to this confusion since much or most of the 
ditaval file seems implementation specific. The Standard talks about 
"processing" as something that isn't completely standardized.

2) The ditaval file format has evolved rather than being designed.
Even if the decision is to include ditaval or something like ditaval 
as part of the DITA Standard, we don't feel that ditaval as it 
stands now is ready to be standardized.  We think ditaval at this
time is mostly what was developed for use with the DITA Open Toolkit 
and that more work would need to be done to be sure that it is ready 
to become more widely used by all other DITA-compliant implementations.

If ditaval were to become part of the Standard, it would be good if 
it could become a mechanism that could tie together everything that 
goes into producing a particular publication.  ditaval doesn't do
that today. 

Today we have a map that defines references to other maps and topics. 
To actually make a publication you need to have the map plus information

from something like a ditaval file (Arbortext uses a .pcf configuration
file), but you also need information on which stylesheets to use, 
what directories to use to resolve relative path references, and I'm 
sure other information that I am forgetting.  It would be good to
have 
a way to tie all of this together. 

Arbortext does not think that ditaval is ready for becoming a normative
part of DITA 1.1.

paul