Concur with Norm
Sent from my iPhone
On Sep 12, 2013, at 1:43 PM, "Paulsen,Norm [Ontario]" <> 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:
> [mailto:] On Behalf Of Gary Ham
> Sent: September 12, 2013 12:24 PM
> To: Gary Ham
> Cc: Tony Mancuso;
> 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 <> 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 <>
> 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
>