Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 53300 invoked by uid 500); 20 Jul 2003 03:45:44 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 53281 invoked from network); 20 Jul 2003 03:45:43 -0000 Received: from smtp-3a.paradise.net.nz (HELO smtp-3.paradise.net.nz) (202.0.32.196) by daedalus.apache.org with SMTP; 20 Jul 2003 03:45:43 -0000 Received: from JESSIE (203-79-120-217.cable.paradise.net.nz [203.79.120.217]) by smtp-3.paradise.net.nz (Postfix) with SMTP id 332D6AE0A4 for ; Sun, 20 Jul 2003 15:45:53 +1200 (NZST) From: "Conal Tuohy" To: Subject: RE: [Vote] Controller/Sitemap integration Date: Sun, 20 Jul 2003 15:51:04 +1200 Message-ID: <006301c34e72$25944c60$d9784fcb@insurgentes.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stephan Michels wrote: > > [...] > > [...] > I think it's a potential source of confusion to have "id" attributes which are not of type ID (i.e. they are not unique identifiers of elements in the sitemap). Of course, I realise that "id" is just an abbreviation for "identifier", and that it's purely conventional that "id" attributes are of type ID, but I think we should respect this very common convention because doing so will lower the cognitive burden for people learning Cocoon flow. http://www.w3.org/TR/REC-xml#id Similarly, a newbie might expect a "state-id" attribute to be of type IDREF, which is a mark against it IMHO. http://www.w3.org/TR/REC-xml#idref And again, that's why I think "src" would be a poor name for the same attribute, because an attribute with this name would conventionally contain a URI. http://www.w3.org/TR/xmlschema-2/#anyURI That's why I'd prefer any other of the alternative names proposed: state, from, continue, or flow. Cheers Con