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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

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


Subject: Re: [emergency-comment] CAP Comments



> Just a quick FYI - registering a mime-type - this is a non-trivial exercise!

Yes I know, thats why the suggestion to get it started now, also why it should be done by the TC which "owns" the spec.  Meeting the requirements for usage is not a problem and it already meets the published standard requirement.

> I suspect that suitable mime-type combos already exist for what you want - xml/text et al may suffice.

Not really, we use it for including in our RSS feeds in order to allow our CAP compliant systems to determine the difference between XML inclusions prior to download.  There was also some work on using CAP with SIP and XMPP where a mime-type would be necessary.

> [drrw] Overall I agree this is good practice.  If null is needed - support it thru an optional attribute codelist - such as:  content="INC"  - where codes are "INC - incomplete" "UNK - unknown" - "NA - not available" and so on - to clarify why the data is not provided at this time.[drrw]
> 

There are currently no XML attributes used by CAP and I would like to see it stay that way.  Too many systems have gone attribute crazy and there is no need at this time for it in CAP.

> [drrw]  various ways of doing this - XLink may be suitable - or a simpler approach with href and attribute carrying state / linkage action codes. [drrw]
> 
> [drrw] recommend avoiding size restrictions - always ends badly! Suggest lists instead - so people can just display the first entry in list - and rest are optional details.  Also list entries can have extensible types - so make rich and simple information pattern [drrw]
>
> [drrw] Look at adding Atom compatiblity instead - no need to re-invent wheel - and media sources already work with Atom feeds. Atom also is extensible - see my notes on event element - same thing applies [drrw]

These suggestions would be a major departure from the current spec and I was only suggesting minor changes in this round of comments.  For lists it would still require limiting the size of the first entry in the list.  It could be done with an instruction element limited to 250 and an instructionLong that is not limited.  There is really no use case where a really long event element would be needed, at least that I've seen.  As for Atom compatibility, can't CAP already be extended using namespace extensions?

-- 
jake@jpw.biz
--


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