Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="info"><ac:parameter ac:name="title">Zend_Validate_Barcode_ISBN13 - Andries Seutens</ac:parameter></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Validate_Barcode_ISBN13 Component Proposal

Proposed Component Name Zend_Validate_Barcode_ISBN13
Developer Notes
Proposers Andries Seutens
Darby Felton, Zend liaison
Revision 1.0 - Initial draft: 3 july 2007 (wiki revision: 10)

Table of Contents

1. Overview

Zend_Validate_Barcode_ISBN13 is a simple component that validates the validity of an ISBN13 barcode.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will validate the validity of an ISBN13 barcode.
  • This component will calculate the proper checksums.
  • This component will not validate a barcode from an image.

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Validate_Abstract

5. Theory of Operation

The component is instantiated with a mind-link that ... it will rock the planet.

6. Milestones / Tasks

  • Milestone 1: [DONE] write proposal
  • Milestone 2: get the proposal approved
  • Milestone 3: working prototype checked into the incubator
  • Milestone 4: write unit test, and check into SVN
  • Milestone 5: write documentation for this validator.
  • Milestone 5: introduce "component" to core.

7. Class Index

  • Zend_Validate_Barcode_ISBN13

8. Use Cases

UC-01: validating barcode
UC-02: retrieving invalid barcode message

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Aug 03, 2007

    <p>Generally, I subscribe to the idea of being flexible with respect to allowed input and being careful with output. This validator filters all characters of the input that are not digits, which meets the first goal - being flexible with input to the validator. But such automatic filtering may also have unintended consequences for users that break the second goal - being careful with output from the validator. Consider the the following:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    // this script is intended to add a new item identified by the POSTed ISBN-13 number

    $_POST['isbn13'] = 'ABC9780465067107 XYZ Corp';

    $barcode = new Zend_Validate_Barcode_ISBN13();

    if ($barcode->isValid($_POST['isbn13'])) {
    // barcode is valid, save it to the database as a new item
    $item = new Item($_POST['isbn13']);
    } else {
    // invalid barcode provided

    <p>In this scenario, the user mistakenly believes that because the input value validates successfully, it is safe to enter it into the database. If, for example, the column type is <code>CHAR(13)</code>, then we have a problem.</p>

    <p>I suggest removing the automatic digit filtering; users can use this validator in combination with <code>Zend_Filter_Digits</code> and <code>Zend_Filter_Input</code> as needed.</p>

    1. Aug 06, 2007

      <p>I agree, but we have to set some rules on how we define a valid ISBN13 barcode then. Eg:</p>

      <ul class="alternate">
      <li>are dashes obligated for a valid isbn? eg "99921-58-10-7" or "9992158107", or both?</li>
      <li>what shall we do with the ISBN prefix? eg "ISBN 99921-58-10-7" Consider it valid, or not?</li>

      1. Aug 07, 2007

        <p>These are good questions, since it is likely that some applications would want to allow input of dashes to be valid, for example.</p>

        <p>I think we should focus on the validation of the barcode number itself, since they are the only characters relevant to the checksum algorithm that the validator performs.</p>

        <p>Let's assume a simple situation where an application accepts some input string to be used as an IBSN barcode for searching a book catalog. The first thing to do is to filter the string of all but digit characters, because only the digit characters matter for the checksum algorithm. The digits are verifed using a validator before tasking the database with a more expensive search operation on the input. This can be achieved by running <code>Zend_Filter_Digits</code> on the input before validating it (e.g., <code>Zend_Filter_Input</code> supports this nicely). If the database stores the ISBN as all digits, then we have no problems. But let's now assume that the database stores the ISBN as a string with dashes in appropriate places (e.g., "99921-58-10-7"). Another [escaping] filter is needed to transform the data from <code>Zend_Filter_Digits</code> (i.e., "9992158107" needs to become "99921-58-10-7"). A custom filter can be written for this purpose rather easily.</p>

        <p>In short:</p>

        <li>dashes are not allowed for input ISBN; they should have been stripped by the time the string is input to the validator</li>
        <li>prefix of "IBSN" is not allowed; any prefixes and suffixes should have been filtered out by the time that the input string reaches the validator</li>

  2. Aug 14, 2007

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>This component is approved for incubator development, during which the issues above may be addressed.</p>

    <p>Also to consider:</p>

    <li>In which formats are ISBNs represented in the barcodes (e.g., just digits, with dashes)?</li>
    <li>Because a barcode is a representation of the ISBN and ISBNs may be in use outside of any barcode usage (e.g., book search), it probably makes sense to have a separate <code>Zend_Validate_Isbn</code> that supports both 10- and 13-digit formats.</li>

  3. Nov 09, 2008

    <p>Just wanted to notify you (in case you didn't already know) that ISBN-13 == EAN-13, for which there is already a validator.</p>

  4. Mar 18, 2009

    <p>This proposal hasn't been updated in the past 6 months. Archiving for now.</p>