- From: <Noah_Mendelsohn@lotus.com>
- Date: Mon, 16 Oct 2000 15:20:44 -0400
- To: <mtimmerm@opentext.com>
- Cc: www-xml-schema-comments@w3.org
Matt Timmermans writes: >> I will assume that all groups with all maxOccurs <= 1 are >> useful in at least some situations, simply because we >> include them in Schema This model is useful for a broad range of cases involving data. Many storage systems (our own Lotus Notes/Domino product comes to mind) have the characteristic that named fields can occur at most once in a document, with order being insignificant. When you store an email in Notes, there is a "From" field, a "To" field, etc., but order is not significant (we have forms that work like stylesheets to lay out a convenient presentation for users, but that is a different issue.) The columns in a relational database are similar: the name is significant, the order is not, and there is at most one with a given name. Indeed, one of the reasons that I was so anxious to get <all> into the language is that I saw many real-world data DTDs with content models like: (name | rank | serial-number)* in which, at the application level, it was clear that either exactly one or at most one of each was expected. The repetition was done merely as an approximation to order-independence. The problem is that a design time tool reading the DTD cannot see this restriction, and cannot establish the obvious mapping to a database or programming language structure. The DTD implies that multiplicity can occur, when in fact it cannot. Another way to look at it is that our current <all> rules happen to map exactly to the rules for attributes on an element: at most once, order does not matter. These rules have surely proven useful in that context. In data scenarious, many sets of elements are used to model characteristics that feel like (structured) attributes of the parent. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Monday, 16 October 2000 15:26:17 UTC