OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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

However, If this does come to pass, I believe it should be confined to
<parameter> only.

My two cents.


-----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>
>> 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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]