[Simple] Expressing XML support for common-policy and extensions

"Thomson, Martin" <Martin.Thomson@andrew.com> Thu, 05 January 2006 04:46 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN15-0004AQ-Nx; Wed, 04 Jan 2006 23:46:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN13-0004AE-W6 for simple@megatron.ietf.org; Wed, 04 Jan 2006 23:46:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19496 for <simple@ietf.org>; Wed, 4 Jan 2006 23:45:03 -0500 (EST)
Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuN6b-0001Mb-CO for simple@ietf.org; Wed, 04 Jan 2006 23:52:06 -0500
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 22:46:03 -0600
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 04 Jan 2006 22:46:03 -0600
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 22:46:02 -0600
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC11B0B37B@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: simple@ietf.org
Date: Wed, 04 Jan 2006 22:45:21 -0600
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 05 Jan 2006 04:46:02.0598 (UTC) FILETIME=[EE44E060:01C611B2]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: Expressing XML support for common-policy and extensions
thread-index: AcYRstV/T+BgLDtkQ+GMh/YIhMYK9g==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Subject: [Simple] Expressing XML support for common-policy and extensions
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1482640787=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

After reading Jonathan's common-policy-caps draft [1] and the related pres-policy-caps [2] and geopriv-policy-caps [3], I came to the realization that the subsequent documents all do exactly the same thing.

Once the protocol components related to XCAP have been dealt with, the specification of a document format and schema is largely a copy-and-paste job.  This is nice in one respect - these documents are very simple and elegant - but a long time spent with code triggers the refactoring neurons.  Where a pattern exists, there is redundant code.

In order to use capabilities, every common-policy extension requires a matching capabilities specification.  That extra specification contains little, or no, additional value.

With this thought in mind I have taken the problem and applied an additional layer of abstraction to create a document format that should address all extensions.  In some way, this is inspired by the elegant simplicity of Schematron [4].  I hope that this one draft will suffice where many would have been before:

http://www.ietf.org/internet-drafts/draft-thomson-simple-expressing-xml-support-00.txt

I think that the solution retains much of the simplicity of the original offering, while providing enough flexibility to accommodate future extensions.  I also suspect that it could be easier to implement, and it will certainly be easier to maintain.

So, I'd like some feedback, if you have time to read the draft.  Is this an acceptable tradeoff between the various factors (simplicity, specification work, etc...)?  I have some ideas on how this could be integrated with the existing capabilities work, is that a good idea?

Cheers,
Martin

[1] http://www.ietf.org/internet-drafts/draft-ietf-simple-common-policy-caps-00.txt
[2] http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-policy-caps-00.txt
[3] http://www.ietf.org/internet-drafts/draft-guenther-geopriv-policy-caps-03.txt
[4] http://www.schematron.com/overview.html

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple