From 614494445a31c590a7be57c99dd56780652f7c6d Mon Sep 17 00:00:00 2001 From: Dave Jones Date: Fri, 16 Oct 2020 14:53:23 -0500 Subject: [PATCH] remove goal 2 - #40 --- README.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 8e5bc99..51532eb 100644 --- a/README.md +++ b/README.md @@ -15,27 +15,20 @@ There is significant overlap amongst the many existing podcast namespaces. Each system and audience the metadata they need in the way they want it delivered. -## Goal #2 - Minimize Attributes and Sub-elements - -Attributes in xml elements should be used only where absolutely needed. The preference is to create a new element type, rather than reuse the same element with -different attributes. For example, instead of using **\**, we would use **\**. This makes the corresponding -aggregator code easier and more linear. Sub-elements should be avoided if at all possible. - - -## Goal #3 - Keep "required" tags minimal +## Goal #2 - Keep "required" tags and attributes minimal The only required tags should be those that solve an overwhelming need in the industry. Requiring tags is a roadblock to adoption and should be avoided. Attributes should also only be required when they are key to the functionality of the tag. -## Goal #4 - Keep Exisiting Conventions +## Goal #3 - Keep Exisiting Conventions Reinventing the wheel helps nobody. When at all possible, existing conventions should be maintained. For example, it would make sense to turn **\** into a unary element, where it's existence is taken as a "yes" and it's absence as a "no". But, that has never been the standard. And, given as how this namespace will probably sit alongside at least one other namespace, it makes sense to keep existing conventions in place. -## Goal #5 - Be General... to a point +## Goal #4 - Be General... to a point There is no way to address every possible metadata point that each platform would want. That is not the aim. Instead we focus on defining the elements that would be useful to the broadest set of apps, publishers, platforms and aggregators. Individual parties can keep their respective supplemental namespaces small and targeted as an adjunct to @@ -44,7 +37,8 @@ this larger namespace. But, we don't want to be so general that the spec become ## The Guiding Principles -Our guiding principles for development of this namespace are the "[Rules for Standards Makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html)" by Dave Winer. Please read it before contributing if you aren't familiar with it. +Our guiding principles for development of this namespace are the "[Rules for Standards Makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html)" by Dave Winer. +Please read it before contributing if you aren't familiar with it.