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

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

12/08/2006 01:51 PM

"Ogden, Jeff" <jogden@ptc.com>
[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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]