Seems pretty open to me? In our latest beta RNC (https://docbook.org/xml/5.2b05/rng/):
div {
db . legalnotice . role . attribute
= attribute role
{ text }
db . legalnotice . attlist
=
db . legalnotice . role . attribute ?
& db . common . attributes
& db . common . linking . attributes
db . legalnotice . info
= db . _info . title . only
db . legalnotice
=
## A statement of legal obligations or requirements
[
s:pattern
[
"x{a}"
~
"
"
rng:title
[ "Root must have version"
]
"x{a}"
~
"
"
s:rule
[
context
= "/db:legalnotice"
"x{a}"
~
"
"
s:assert
[
test
= "@version"
"If this element is the root element, it must have a version attribute."
]
"x{a}"
~
"
"
]
"x{a}"
~
"
"
]
]
element legalnotice
{
db . legalnotice . attlist , db . legalnotice . info , db . all . blocks +
}
}
The content is db.all.blocks+
--Scott
From: <
docbook-tc@lists.oasis-open.org> on behalf of "Rowland, Larry" <
larry.rowland@hpe.com>
Date: Monday, January 7, 2019 at 10:59 AM
To: Bob Stayton <
bobs@sagehill.net>, "docbook-tc@lists.oasis-open.org" <
docbook-tc@lists.oasis-open.org>
Subject: RE: [docbook-tc] legalsection versus section in legalnotice
Just a note of clarification. I think that legalnotice should allow legalsection elements at its end, too. That way, complex legal
notice structures would be allowed inside info to accommodate singular notices that require complex structure and legalsections would be available outside of info to accommodate the requirement for things like including all the licenses for open source software
used in a complex, enterprise-level project.
Regards,
Larry Rowland
From:
docbook-tc@lists.oasis-open.org [mailto:
docbook-tc@lists.oasis-open.org] On Behalf Of Bob Stayton
Sent: Monday, January 7, 2019 10:06 AM
To:
docbook-tc@lists.oasis-open.org Subject: Re: [docbook-tc] legalsection versus section in legalnotice
Continuing this discussion in preparation for our meeting on Wednesday, Larry had the last word on this after heard from everyone including Norm.
In Larry's new model, legalnotice remains confined to info, and legalsection is the element that would appear in normal content. They would have the same content model, except
legalsection could contain nested legalsections at its end.
I think this accomodates the requirements and is easier to understand, as Larry says.
Norm asked about formatting issues like enumeration, and I think legalsection should be treated as all other members of the section class by default. Someone could always customize
that if they want something different.
The only thing I want to do is review the content model of legalnotice to be sure it can serve as both legalnotice and legalsection.
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net On 12/11/2018 7:10 AM, Rowland, Larry wrote:
Interesting discussion. Good to hear from Norm.
Something that occurred to me recently is a model that adds a legalsection that has the same content as a legalnotice (including legalsections). This would accommodate the increased complexity of content that some legal notices are starting to need.
Then, if legalsection is allowed anywhere that a section (or simplesect -- I hadn't thought of that) is allowed, it would be easier to understand than intermixing legalnotices with sections and would follow the same rules as sections about intermixing with other content. This would be to accommodate situations like those documents that combine lots of open source licenses to meet licensing requirements for all of the open source components that are included in a deliverable. I think mixing legalnotice with section would be harder to understand than mixing legalsections with sections.
Regards,
Larry Rowland
Original Message-----
From: docbook-tc@lists.oasis-open.org [ mailto:docbook-tc@lists.oasis-open.org ] On Behalf Of Norman Walsh
Sent: Tuesday, December 11, 2018 4:13 AM
To: docbook-tc@lists.oasis-open.org
Subject: Re: [docbook-tc] legalsection versus section in legalnotice
Bob Stayton <bobs@sagehill.net> writes:
Thanks for your quick responses. If we are going to allow legalnotice
outside of info, then we have do settle what class of element it will
be so we can determine how it fits into other content models.
My two cents from the peanut gallery: I d add it to db.nopara.blocks.
Possibly by creating a new pattern, maybe db.notice.blocks or something. It strikes me as *almost* being a candidate for putting in admonitions. But a new pattern is probably best.
Most of our elements can be classified as hierarchical, block, or
inline. The current legalnotice would be considered a block element
and could appear anywhere within a section alongside tables and paras
and figures. If a new legalnotice contains sections, doesn't that make
it a kind of section itself? That is, could you put a legalnotice in
the middle of a section, add subsections to it, and continue with
block content after the legalnotice closing tag? We don't allow block
content after a regular section.
Yeah. I d be really reluctant to allow section in legalnotice for just that reason. (If the TC decides to allow section in legalnotice which is a block like thing, then it s worth revisiting if section should be allowed in other blocks, like sidebar, I expect.)
The bridgehead element can always be used to simulate a title; all you d be missing is truly nested hiearchy and I wonder if that s justifiably necessary.
Perhaps if it is going to be in content, then we should just call it
legalsection, and allow it as another flavor of section wherever
section is allowed? It could contain nested legalsections as needed.
That wouldn t be my first choice, but I suppose it could be made to work. Lots of complicated questions with no obviously right answers, such as, how would one expect them to be enumerated?
And the question of where does it fit into the sect1 vs section vs simplesect hierarchy arises. I d be tempted to make it behave like simplesect, myself.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> To think is not enough; you must think
http://nwalsh.com/ of something.--Jules Renard