Re: [emergency-cap] HTML in CAP <description> OK?

[Gary Ham <gham@grandpaham.com>]

Concur with Norm

Sent from my iPhone

On Sep 12, 2013, at 1:43 PM, "Paulsen,Norm [Ontario]" <Norm.Paulsen@ec.gc.ca> wrote:

> I know that even fully escaped, many consumers of CAP would not be able
> to process it. It's the balance of "Keeping it simple" for CAP consumers
> (at all levels of ability) vs. the ability of issuing individuals and
> communities to extend CAP to take care of the extra stuff that they want
> included. In essence, turning CAP into a wrapper just to take advantage
> of CAP to distribute one's native XML, or some html text for web
> browsers, or whatever, was not the intent of the CAP authors (especially
> if doing this in <description>).
> 
> Personally, I believe that allowing this is against the original intent
> of the CAP authors to keep things simple. I believe they avoided these
> things to  broaden the uptake of CAP without the average consumer
> getting scared off because of things such as this (<parameter> being a
> classic example of controlling stuff like this). CAP was built more for
> public message distributor's (consumers) getting information in a simple
> standard way rather than issuers getting all their variations covered
> off.
> 
> So technically it's still interoperable with doing this, but
> realistically it not. It will result in more proprietary systems on both
> the issuing and consuming sides. Public domain will slowly become
> private domain. The majority of consumers won't have such tightly
> written processors, and if they do, it will be on a case by case basis.
> Also, building something to eliminate escaped stuff they can't handle is
> also not something they want either. 
> 
> I feel that when looked at on the broad scale and in the long run, the
> overall gain on the issuer side will be less than the loss (drop off) on
> the consumer side. On the small scale things would work and work faster
> but interoperability will be hit hard and CAP itself will lose some
> relevance.
> 
> However, If this does come to pass, I believe it should be confined to
> <parameter> only.
> 
> My two cents.
> 
> Norm
> 
> 
> -----Original Message-----
> From: emergency-cap@lists.oasis-open.org
> [mailto:emergency-cap@lists.oasis-open.org] On Behalf Of Gary Ham
> Sent: September 12, 2013 12:24 PM
> To: Gary Ham
> Cc: Tony Mancuso; emergency-cap@lists.oasis-open.org
> Subject: Re: [emergency-cap] HTML in CAP <description> OK?
> 
> oops I mean fully escaped HTML. Typo on my part.
> 
> 
> On Sep 12, 2013, at 12:22 PM, Gary Ham <gham@grandpaham.com> wrote:
> 
>> My answer would be that it must be fully escaped, but the real issue
> is that most consuming applications are not expecting it and are
> unlikely to render it correctly.  I know that this is true for most of
> my stuff.  But fully escaped xml might be a way around structured info
> inside a <parameter><value>.  
>> 
>> vr,
>> 
>> 
>> Gary A. Ham
>> http://grandpaham.com
>> 703-899-6241
>> 
>> 
>> 
>> 
>> On Sep 12, 2013, at 12:09 PM, Tony Mancuso <amancuso@google.com>
> wrote:
>> 
>>> I seem to recall that the EMA-TC C&D SC removed advice in the Best
> Practices: CAP elements doc NOT to insert HTML in CAP elements (such as
> in the <description> element. Does anyone have feedback on this
> practice, pro or con?
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>