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] How should the spec handle statements about rendering expectations?


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 <dita@lists.oasis-open.org> on behalf of Don Day <donday@donrday.com>
Date: Tuesday, February 9, 2016 at 2:06 PM
To: dita <dita@lists.oasis-open.org>
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


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