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

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



http://dita.xml.org/blog/25

"Grosso, Paul"
<> 

12/08/2006 01:51 PM

To

<>

cc

"Ogden, Jeff" <>

Subject

[dita] ditaval should not be normative
in 1.1

> -----Original Message-----

> From:  [mailto:] 

> Sent: Tuesday, 2006 November 28 09:53

> To: 

> 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