Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54, <table>

Carsten Bormann <cabo@tzi.org> Sat, 06 October 2018 18:15 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC3130DEE for <xml2rfc-dev@ietfa.amsl.com>; Sat, 6 Oct 2018 11:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjRjXec51-3Q for <xml2rfc-dev@ietfa.amsl.com>; Sat, 6 Oct 2018 11:15:27 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D201128CE4 for <xml2rfc-dev@ietf.org>; Sat, 6 Oct 2018 11:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w96IFNmw007335; Sat, 6 Oct 2018 20:15:23 +0200 (CEST)
Received: from client-0086.vpn.uni-bremen.de (client-0086.vpn.uni-bremen.de [134.102.107.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42SFCv00kszDWNg; Sat, 6 Oct 2018 20:15:22 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f36e6a80-99ad-fd1a-f872-9b8fc83fb763@levkowetz.com>
Date: Sat, 06 Oct 2018 20:15:22 +0200
Cc: XML Developer List <xml2rfc-dev@ietf.org>
X-Mao-Original-Outgoing-Id: 560542520.518132-462edb73faa197708768eb088245b2a6
Content-Transfer-Encoding: quoted-printable
Message-Id: <602D0951-0A16-4B51-BF69-96D5766BD2B0@tzi.org>
References: <70ee4cff-7533-13e0-d71a-ffecf2dc56f0@gmx.de> <24828f94-dbbd-4c18-8d85-333487bda367@levkowetz.com> <3ac63652-2df2-03c7-eee6-bad2cbd326d8@levkowetz.com> <B63F3A7C-AAB6-4281-BC5F-BC28E9693E43@icann.org> <2ab7b797-4a01-5327-10fb-5ae13587944f@nostrum.com> <a9cbe9b1-1ee4-b60b-bb88-d07d11afa6a3@gmx.de> <20181004192423.xexbgomdqs56pkok@miek.nl> <5694D337-A88C-4F3E-AE2D-8EA34C3A5A93@icann.org> <20181004193939.szec4ng47kp7lapv@miek.nl> <38897ac0-44a7-6b03-4e7e-e19a115fc53d@gmx.de> <f36e6a80-99ad-fd1a-f872-9b8fc83fb763@levkowetz.com>
To: Henrik Levkowetz <henrik@levkowetz.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/4-B8IJB2Q8oSkC_nXansk5Ad_Jc>
Subject: Re: [xml2rfc-dev] RFC 7991 issue #31: Schema Issue, RFC 7991, In Section 2.54, <table>
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Oct 2018 18:15:30 -0000

On Oct 6, 2018, at 18:32, Henrik Levkowetz <henrik@levkowetz.com> wrote:
> 
> <table>
> has no provisions for having a caption.  The discussion subsequently
> sorts this out, pointing to the use of the <name> element for a table
> in order to provide the caption.

In document vocabularies, it generally has turned out to be not so bright to use attributes to store text to be rendered, as sooner or later you will want this text to have more structure (which attributes can’t).

Grüße, Carsten