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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-ccbp-analysis message

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


Subject: Re: CC Requirements : RE: Formal Protest from XMLGlobal.


Scott

> In Tokyo, we spent a good amount of time Thursday reviewing the
information
> model with Chris Nelson.  We discovered that much of the model easily maps
> to the existing RIM, and later that day resolved the "context" issue.
> Therefore the CC information model can potentially become the scheme for
> retrieving any CC information from a registry. The principle is that what
> you put in is what you get back out.  The level of specificity is up to
you
> and is determined by the CC scheme and its mapping to the RIM.  We agreed
to
> assist CC in developing an Implementation Guide to assist in this process.

> However, I am concerned about a few things:
> 1) Requirements need to flow through the Requirements Project Team who
> resolves interdependencies between Project teams.

I'm not up on the management side of the process. I leave that to James
Whittle and Mary Kay, who I sent the revised requirements statement to on
14th December for them to process as required by the procedures. (I note
that James sent you a copy of the Tokyo version on 13th Dec.) The only
reason I sent you a copy of the revised version was because you specifically
stated that you had not received them. Where they got lost in the wash is
not for me to determine.

> 2) There seems to be a requirement to be able to resolve entity references
> directly from a DOM parser (second and third paragraph); interaction with
> the registry currently requires TRP which was a StC decision.  At this
time
> every request to the Registry needs authentication. RR discussed session
and
> state management which could potentially assist direct DOM interaction
with
> the Registry.  That too would require at least the first request (during
> bootstrap) to authenticate and establish a session.  The issue is state
> management, as that leads to security vunerability.  As such, RR is not
> supporting session and state management by the Geneva release, but
possibly
> by the  Vienna release.

The DOM requirement comes from CC team members, though personally I'd rather
you returned what you had submitted, a set of XML Schema declarations. Their
argument is that the applications will not want to deal with the Schemas
themselves, but would want to be able to make calls to the registry using
the same mechanisms they would if they did interface the Schema. I was
presuming it would simply mean the registry passing the stored data to a
Level 3 DOM aware parser and then allowing the applications to interface the
output of the parser. Obviously this will be difficult if you insist on
requiring authentication for each request rather than for a session.

Martin Bryan



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC