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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: RE: [emergency] Re: [emergency-comment] RE: Content ( was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)


>I do not disagree at all with this statement. I just feel like we are
at Square 1/2 - not 1. There are certainly roads I have been down
before that didn't pan out that are not reflected in 1.0, which is why
it doesn't surprise me we are seeing some of the comments we are on
both our list and the CAP list.

On the point of 'almost there but not quite' I would be interested to hear
from other people who have implemented CAP and the CAP schema. We had to do
some modifications to get it to work on strongly-typed parsers, and right
now we are sitting with two extra schemas for two platform implementations.
In that sense, 1.5/2 is true. However due to the fact that we have a stable
transport which is flexible enough to accomodate any filetype, transporting
CAP has been a literal no-brainer.

>Do you have over 1,000 possible systems that generate alerts (or
consume depending on the role of your system)? Basically, do you have
over 1,000 connectors that you have to build? I am using the word
"limit" in terms of whether or not you have a finite number of
potential connectors you have to build.

With a subscriber base worldwide of more than 20 million smartcards spanning
two to three dozen platforms, yes, even 0.5% of that for CAP deployment
would be > 1000. But the fact that you have 1000 systems doesn't mean you
have 1000 different implementations. Its also impossible that it will ever
be down to the wire of one single protocol and transport. Connectors will
always be required when working with different arms of the government or
private sector.

>Its not because every page's use of the <img> tag is different. It is
due to the number of standards it supports - not the number of
variations of the standards it supports. I use to work for a company
that had a formal relationship with Netscape, and they use to embed our
code.

Would that be <img src=blah.gif> <img src = "blah.gif"> <img src=blah.gif/>.
Its the lexical parsing nightmare within the DOM that adds to the bloat,
more than any variation/combination of DOM parsers. And Netscape always was
one of the most bloated ;-). But thats just my humble opinion.

Cheers
Kon


***********************************************************************************
Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.
*********************************************************************************** 


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