I don't disagree with Don's analysis but I think the practical reality is that both authors and implementors expect to find at least some basic guidance about formatting in the spec, if for no other reason than that's where they found in the past.
That said, this is DITA. We could have a separate document that holds all the formatting discussion and then use parts of it by reference as non-normative content in the language reference.
Cheers,
Eliot
----
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
From: dita <> on behalf of Don Day <>
Date: Tuesday, February 9, 2016 at 2:06 PM
To: dita <>
Subject: Re: [dita] How should the spec handle statements about rendering expectations?
I agree with Eliot but have an even stronger feeling about how to
separate OASIS from implementation concerns. The <q> element
text is a good example:
On 2/9/2016 8:40 AM, Kristen James
Eberlein wrote:
Authors
should not add quote punctuation manually when using the <q> element.
That statement is pure specification: this point ensures that the
resulting authored content is interoperable with any DITA-based
process, whether rendition, translation, editing, or more. I would
expect this to be normative because it affects the quality of the
DITA source.
Processors
that render the <q>
element SHOULD add
appropriate styling, such as locale-specific quotation marks.
This statement however is purely implementation and has no impact on
the source itself--you could say "should make it flashing blue on a
reverse magenta background" and it would not affect the spec or
require OASIS 'SHOULD' treatment. Even HTML5 tends to say
"send the q element on through to the browser and let your
locale-dependent CSS take care of the punctuation" (although there
are issues with full stops in quotations -- .</q> vs
</q>. -- that may need explication in the spec).
But because this sentence was in the spec, it was easy for someone
to scan and to flag as requiring OASIS differentiation, which I
argue is pointless here because this is not part of the language
specification and therefore could even be relocated into a
non-normative implementation document that we've discussed before
(my preference now being something that could be maintained and
freely extended on a community wiki like dita.xml.org).
The main point here is just the consideration of "interoperable
source" as a way to sense normative from non-normative (and in this
case, potentially relocatable) discussion.
--
Don R. Day
Founding Chair, OASIS
DITA Technical Committee
LinkedIn: donrday Twitter:
@donrday
About.me: Don R. Day Skype:
don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
This email has been sent from a virus-free computer protected by Avast.
www.avast.com
