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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

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


Subject: RE: [wsia][wsia-requirements][E905]


Title: Message
I also support the usage of must in this case.
 
The question of fragments generated by the same Producer (= WSIA Web Service) relates to the "harder" case where you need to place two services of the same service on the same page (e.g., two stock quotes):
- The reason why this "harder" is because one can't assume a "static" unique token (such as a namespace or a prefix) to ensure uniqueness.
- The need for this requirement is clear; its importance is not completely obvious; there seems to be a strong sentiment in this committee (including myself) that it's important enough to consider.
 
How about the following: emphasizing that there could also be multiple services, but also a single one:

This specification MUST provide a mechanism that ensures that different presentation fragments (generated either by multiple WSIA
Web Services or by a single one)
can be "safely" combined to a single document. In particular, if a presentation format (such as HTML) mandates uniqueness of tokens in a single document, it MUST be possible to compose a page in a way that guarantees uniqueness.

-----Original Message-----
From: Timothy N. Jones [mailto:tim@crossweave.com]
Sent: Monday, May 06, 2002 2:11 PM
To: Eilon Reshef; wsia@lists.oasis-open.org
Subject: RE: [wsia][wsia-requirements][E905]


I mostly like the Eilon version.  Is there a reason not to replace "should"
with "must"?  Also, I don't see why the case of combining multiple fragments
from the same producer needs specific mention (is it more technically
important than composing fragments from different producers?).

I suggest:

  This specification MUST provide a mechanism that ensures that
different presentation fragments can be "safely" combined to a single
document. In particular, if a presentation formats (such as HTML)
mandates uniqueness of tokens in a single document, it MUST be
possible to compose a page in a way that guarantees uniqueness.

Tim

> Can we clarify the intent?

> Is the intent to ensure uniqueness of HTML ids and the question of how
> to do it?

> If this is the case, would it make sense to try to capture the abstract
> need, along the lines of:

> E905A
> This specification should provide a mechanism that ensures that
> different presentation fragments can be "safely" combined to a single
> document. In particular, if a presentation formats (such as HTML)
> mandates uniqueness of tokens in a single document, it should be
> possible to compose a page in a way that guarantees uniqueness. In
> particular, it should be possible to compose presentation fragments
> generated by the same Producer.

> (We can still leave it open to whether the Producer generates random
> token, the Consumer rewrites tokens or the Consumer provides information
> that allows the Producer to write those tokens)


> -----Original Message-----
> From: Alan Kropp [mailto:akropp@epicentric.com]
> Sent: Friday, May 03, 2002 9:56 PM
> To: 'wsia@lists.oasis-open.org'
> Subject: [wsia][wsia-requirements][E905]
> E905
>                 The specification must provide a means by which
> Producers
> may indicate tokens which need to unique to its output. Debate: SR, AK,
> TC,
> SF, SA, ER, RT.
> Try:
> E905
> The specification must provide a means by which a Producer may specify a
> token naming format which indicates to the Consumer which tokens in the
> generated markup stream should be unique to that Producer with respect
> to
> other Producers the Consumer has integrated.
> ----------------------------------------------------------------
> 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