MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia][wsia-requirements][R905 and 601]
I think all these levels are appropriate at times:
- Requirements on the specification: Guidelines for the TC as it writes
the spec.
- Requirements on Producers & Consumers: Processing models and semantics
- Requirements on artifacts: Restrictions on the artifacts that are
exchanged as part of the protocol.
Some requirements have implications on all of these levels. This particular
one places requirements on an artifact (eg. Presentation Fragments), on the
TC (eg. minimal restrictions on markup types) and Producers/Consumers (eg.
setting & processing whatever the spec defines as the standard means to
achieve unique tokens).
"Monica Martin"
<mmartin@certivo. To: "Rex Brooks" <rexb@starbourne.com>, Rich
net> Thompson/Watson/IBM@IBMUS, <wsia@lists.oasis-open.org>
cc:
05/22/2002 01:20 Subject: RE: [wsia][wsia-requirements][R905 and 601]
PM
This gets back to my question today. Is the use of "specification" to
mean the WSIA Web Service. What can a specification do? Perhaps the
answer is "Provide the capability for xx to do yy."
Thanks, Rex.
Monica
-----Original Message-----
From: Rex Brooks
Sent: Wed 5/22/2002 11:18 AM
To: Rich Thompson; wsia@lists.oasis-open.org
Cc:
Subject: Re: [wsia][wsia-requirements][R905 and 601]
Could we possibly change the construction of our requirements
so
that
it is the Specification which MUST, MUST NOT provide, preclude
etc?
When we say Presentation Fragments MUST be capable.... what we
are
saying is that the Presentation Fragment MUST be thus or such,
when
what we mean is that the Specification MUST make it so that
the
Presentation Fragment can be capable... We all know what we
mean, but
it bothers me a little that our thinking seems to need to take
a
rather, hmmmn (insert a PC term here) transposed form.
Sorry. It's nitpicky, but clarity isn't easy.
Ciao,
Rex
At 10:02 AM -0400 5/22/02, Rich Thompson wrote:
>Couple of points:
>- Thomas has pointed out in an initial WSRP pass through this
document that
>we will fail if multiple presentation fragments can not be
combined into a
>single page ... therefore change to MUST.
>- There is also an intent to keep restrictions to the minimum
and a note
>that they will be type specific.
>
>Suggest rewording to:
>
> Different Presentation Fragments MUST be capable of being
combined in
> a single document. This MAY require specification of
restrictions
> specific
> to various markup types or Presentation Fragments, but
any
such
> specification
> of restrictions MUST be minimized. If a markup type
(such
as HTML)
> mandates
> uniqueness of tokens in a single document, a page SHOULD
be
composed in
> a
> way that guarantees uniqueness. In particular, multiple
Presentation
> Fragments
> generated by the same Producer SHOULD be capable of being
combined.
>
>
>
>
>
> Monica
>Martin
> <mmartin@certivo. To: Rich
>Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org
> net>
>cc:
> Subject: WSIA
>5/21/2002: [wsia][wsia-requirements][R905 and 601]
> 05/21/2002
>08:43
>
>PM
>
>
>
>
>
>
>
>Several ideas:
>
>Composition of presentation fragments onto a page
>
>Composition of different presentation fragments onto a page
>
>Composition of different presentation fragments generated by
a
producer
>(May be the same as above)
>
>Restrictiions on presentation fragments (or markup types)
>
>Guarantee uniqueness of tokens in a single document defined
by
the
>presentation format
>
>
>
>
>
>E905 and E601
>
>Notes: [mm1: Namespace entity rewriting Javascript; Consumer
with
>multiple Producers? Need justification. Include with
presentation
>fragments (Consumer passes Producer a key).]
>
>
>
>Suggested text:
>
>Different Presentation Fragments SHOULD be capable of being
combined in
>a single document. Restructions MAY be specified on markup
types or
>Presentation Fragments. In particular, if a presentation
format (such
>as HTML) mandate uniqueness of tokens in a single document, a
page
>SHOULD be composed in a way that guarantees uniqueness. In
particular,
>Presentation Fragments generated by the same Producer SHOULD
be
capable
>of being composed.
>
>
>
>Comments and arrows welcome.
>
>Thanks.
>Monica J. Martin
>
>Program Manager
>
>Drake Certivo, Inc.
>
>208.585.5946
>
>
>
> -----Original Message-----
> From: Rich Thompson
> Sent: Fri 5/17/2002 1:33 PM
> To: wsia@lists.oasis-open.org
> Cc:
> Subject: [wsia][wsia-requirements][R130]
>
>
>
> Here are the modified requiremetns documents
...
the 'a'
>version
>is prior
> to accepting changes and rearranging the
requirements by
>functional
> categories. In addition to those changes, the
'b'
version has
>consistent
> capitalization of words like 'MUST' and
Consumer.
I also noted
>and
> implemented the global change of 'property' to
'context data'.
>
> (See attached file: WSIA reqs
2002-05-17a.doc)(See attached
>file: WSIA reqs
> 2002-05-17b.doc)
>
> Requirements still needing attention include:
> R201
> R203
> R130
> Overlap between R601 & E905
> Overlap between R702 & E904
> Monica's recent email:
> WSIA Web Services SHOULD provide the
capability for
>those
> Presentation
> Fragments, returned by the Producer,
can
be requested
>and relayed
> through the Consumer.
> WSIA Web Service SHOULD provide the
capability for
>Presentation
> Fragments to reference end-user
requests
for external
>resources.
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the
subscription
>manager: < http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the
subscription
>manager: < http://lists.oasis-open.org/ob/adm.pl>
--
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: < http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC