W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2015

Re: role "statement"

From: Shane McCarron <shane@aptest.com>
Date: Thu, 19 Feb 2015 10:33:09 -0600
Message-ID: <CAOk_reFzyd8RzHo_zLz=kwxqtkgb31gmrsQHcqQJKS=cNMVdAg@mail.gmail.com>
To: Bill Kasdorf <bkasdorf@apexcovantage.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>, "DPUB-ARIA (public-dpub-aria@w3.org)" <public-dpub-aria@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
I don't think we are in a good position to suggest new elements for HTML at
this juncture anyway.  A new role seems more in scope.  And statement is a
reasonable one.  It has clear, distinct semantics.  That's a good litmus
test for any new value for @role.

On Thu, Feb 19, 2015 at 10:29 AM, Bill Kasdorf <bkasdorf@apexcovantage.com>
wrote:

>  +1 but with some further thoughts. And thanks for the mention of
> NLM/JATS/BITS which imo has a lot of other handy features of interest
> (milestones come immediately to mind, for example, which get you out of the
> well-formedness pickle).
>
>
>
> One thought on <statement> though: I wonder if it should be a phrase level
> element. While you're correct, a "statement" is usually set off quite
> clearly (but can occur at any level), I can envision a publisher needing to
> identify a formal statement that is contained within a paragraph, for
> example.
>
>
>
> Here is a possibly relevant use case (but maybe not) from one of my
> clients, a standards publisher. Their standards typically begin with a
> chapter consisting of formal definitions of terms, and when any of those
> terms are used in the content _*in that formal sense*_ (in any form, e.g.
> plural or singular, various verb forms, etc.) that word or phrase is
> explicitly tagged as such (but not when the same word is used not in that
> formal sense), and specially formatted in rendering (bold italic in print,
> red online, etc.). So that has the sense of "formal" but it really doesn't
> have the sense of "statement." Hmm.
>
>
>
> And at the other end of the scale, very complex content can be a formal
> statement, as you mentioned: e.g., in law, a judicial ruling, a statute, an
> ordinance, etc.
>
>
>
> Which makes me wonder if really this shouldn't be a @role attribute value
> after all. That way any available structural component of a document can be
> designated as a "formal statement" or even just "formal".
>
>
>
> --Bill K
>
>
>
> *From:* Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
> *Sent:* Thursday, February 19, 2015 10:08 AM
> *To:* DPUB-ARIA (public-dpub-aria@w3.org); W3C Digital Publishing IG
> *Subject:* role "statement"
>
>
>
> Hi,
>
>
>
> As per today's DPUB-ARIA call, I wanted to separate out an item from an
> earlier discussion in December.
>
>
>
> I would like to propose a role "(formal) statement".
>
>
>
> Here's a work-in-progress definition.
>
>
>
> A minor structural division in a work, typically encapsulated in a major
> division. A fragment that is part of the overall flow (i.e., not an aside)
> but is distinguished from the surrounding content (often typographically)
> and might be referenced elsewhere (in particular, often carries a label).
>
>
>
> Among other things, statements are content fragments that might be
> aggregated in some form of index (comparable to figures).
>
>
>
> Use cases come from humanities (postulate), law (via Bill Kasdorf),
> sciences (hypothesis, experiment, ansatz, result, example), math (theorem,
> proof, definition, proposition, lemma, corollary).
>
>
>
> Statements are similar to figures except it's more textual and never
> floating. In HTML5, I'd expect it to be mostly applied to <section> though
> <p> or <div> might often work, too.
>
>
>
> Looking at the already proposed roles, statement appears a bit meta --
> question, answer, practice seem to be statements, too. For full disclosure,
> a <statement> element is part of NLM/JATS/BITS.
>
>
>
> Best regards,
>
> Peter.
>



-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Received on Thursday, 19 February 2015 16:33:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:55 UTC