Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

RE: information bulletin

[Subject Prev][Subject Next][Thread Prev][Thread Next]
Richard,

First, I should apologize and offer a correction to my own post.  ACI
360R-92 could be a standard (but it is not) yet still be in non-mandtory
language.  The ACI TCM (Technical Committee Manual) does in fact permit the
creation of non-mandatory language standards by ACI committees.  The primary
difference between a standard and a non-standard being the more rigorous
process that a standard must go through in  order to be approved including a
public comment period.  Thus, while I did not strictly state the since ACI
360R-92 was not a standard and that was the reason it could not be reference
in the code, that is at the time what I intended to say and it certainly
could be implied.  What said, however, is still techinically correct.  ACI
360R-92 is _NOT_ a standard.  Even if it was a standard (meaning that it
goes through ACI's standardization process and thus is then likely to and
meant to be recognized by ANSI as an "American Standard"), it is written in
non-mandatory language, which means that it should not/cannot be reference
by a code and/or contract specifications/documents.

It is my understanding the NFPA 5000 would only adopt recognized standards
written in mandatory language by reference (i.e. standardized code or
specifications).  And to my knowledge, they have not deviated from this
intent.  If NFPA is referencing documents written in non-mandatory language
in the NFPA (which I have not seen), then they better start hiring a bunch
of lawyers because they will be a LOT of people who can challenge things in
the NFPA 5000.

I agree with you 100% that such methods in ACI 360R-92 do not need to be in
mandatory language to be permitted for use.  But, there is a BIG difference
between being PERMITTED and REQUIRED/MANDATED.  My point was that if you put
forward ANY legally binding document (code and/or project
specifications/documents) that REQUIRE/MANDATE the use of ACI 360R-92 or
parts of the document, you better be prepared to potentially lose in court
if someone whats to challenge you on it.  Since ACI 360R-92 is written in
non-mandatory language, it basically says that "you may do this or you may
do that" and included in that is an implication that you "may do nothing".
In otherwords, all ACI documents with an R in them don't really tell you
that you HAVE TO do ANYTHING, but rather gives recommendations on what you
may do if you so choose.  Thus, there are completely inconsistant with
telling someone that they are required to do something.  It even becomes
difficult to say "you must do the design of slab on grade using the PCA
design method in section 5.2 of ACI 360R-92" because that whole section is
still written in non-mandatory language.  Thus, it would be possible for
some to say that I designed it by the PCA method but choose to not follow
some of the items in that method because I did not like them and they were
not written such that I _HAD_ to follow them (even though that was the
intent).

So, if your informational bulletin is just that "for information only" and
does not require anyone to do anything, then referencing ACI 360R-92 would
be 100% fine.  In otherwords, if you put out a bulletin that basically says
"hey, for good design methods to use for slabs on grade, you might want to
look at ACI 360R-92" (ACI certainly would like that), then you are golden.
If, however, the intent of your informational bulletin is to place
requirements on designers in some way (even if it is just "from a large
city" rather than a national building code), then you are basically wasting
your time referencing ACI 360R-92.  If you really want to require things and
methods that are contained in a document like ACI 360R-92, then you need to
spell out in your own MANDATORY language which SPECIFIC items and methods
(including all the parts and subparts of that method) that you wish to be
required.  Otherwise, you are potentially faced with the possibility that
someone will turn around and say "oh, I designed it per ACI 360R-92 which
has as one of its implied methods of design (since written in non-mandatory
language) to not use any of the design methods contained in the document".
Thus, the end result is that you required following ACI 360R-92, they
"followed" it but not in the way you intended, and now the whole thing goes
to court and more than likely they win.

But far be it for me to tell you what to do or not to do.  If you want to
REQUIRE the use of ACI 360R-92, go right ahead.  Just make sure that you
have plenty of lawyers around to try and enforce it.  Some just want to do
things the hard way.  After all, I won't have to be reading through a list
of 130 some canidates for govenor in the next month or so (I know...a rather
cheap shot).  <grin>

Regards,

Scott
Ypsilanti, MI

-----Original Message-----
From: Richard Hess [mailto:rlhess(--nospam--at)hesseng.com]
Sent: Tuesday, August 26, 2003 9:09 PM
To: seaint(--nospam--at)seaint.org
Subject: Re: information bulletin


Scott,
Thanks for your comments.  I agree that you cannot just reference ACI
360R-92 in a building code even if it was a full "standard".  In fact that
is one of the main reasons we are telling our politicians in Sacramento,
California that  they should not adopt the NFPA 5000 building code because
it tends to do just that.
You do not need code language to use one of the methods in ACI 360R-92 now
any more than you need specific code language to use API 650 or AWWA D100 to
design tanks and reservoirs.  They are accepted methods of design to cover
things that are not covered in the code.  However, a lot of people,
including many plan checkers need help on understanding what constitutes a
good design of these slabs.  An information bulletin from a large city,
while not a part of a national model code, will definitely clear up a lot of
misconceptions in this region and may just provide the impetus to eventually
get something in the building code.
My mail was not announcing a result, but rather, inviting comments such as
yours and participation by a few engineers in examining this subject and
recommending language to shed light.
Like the old saying, a long trip starts with the first step.
 Richard Hess




******* ****** ******* ******** ******* ******* ******* ***
*   Read list FAQ at: http://www.seaint.org/list_FAQ.asp
* 
*   This email was sent to you via Structural Engineers 
*   Association of Southern California (SEAOSC) server. To 
*   subscribe (no fee) or UnSubscribe, please go to:
*
*   http://www.seaint.org/sealist1.asp
*
*   Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you 
*   send to the list is public domain and may be re-posted 
*   without your permission. Make sure you visit our web 
*   site at: http://www.seaint.org 
******* ****** ****** ****** ******* ****** ****** ********