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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: RE: [ebxml-cppa] "IMPLIED" keyword


Marty,

the schema says:

<element name="ConversationConstraints">
		<complexType>
			<attribute name="invocationLimit" type="int"/>
			<attribute name="concurrentConversations"
type="int"/>
		</complexType>
	</element>

Because the "use" attribute is omitted on the attributes named
"invocationLimit"
and "concurrentConversations", they have their default value which is 
"optional". So I think we are OK because IMPLIED is roughly like
optional.
[and we avoided optional because of the key word problem as you
suggest.]

Whether this makes some difference to Post Schema Validation Infosets
or not, is --I hope-- something we haven't worried about.

At least I don't remember this group worrying about it. If we do want
to worry about what the infoset looks like after schema validation,
we can fix those matters and the use of the term IMPLIED later on
when people settle issues concerning PSVI.

I will try to check out whether there are any use="value"
incompatibilities
with the text over the next week. I think Arvola had checked those
already
though.

Dale

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, October 02, 2002 8:41 AM
To: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] "IMPLIED" keyword






Further thought:

In many cases, I think that the text in the CPPA spec is using the word
IMPLIED as a circumlocution for "optional".  Aside from the specific
case
of invocationLimit and concurrentConversations, where the correct word
seems to be REQUIRED, IMPLIED in a DTD carries the notion that it's up
to
the XML application to figure out what to do if the attribute is
missing,
which is more than just "optional".  For cases where the attribute might
or
might not be present, we still don't want to use the word OPTIONAL
because
if its RFC2119 implications for implementers. We will need a different
circumlocution such as explicitily stating something like "(cardinality
0
or more).

Regards,
Marty


************************************************************************
*************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
************************************************************************
*************
----- Forwarded by Martin W Sachs/Watson/IBM on 10/02/2002 11:40 AM
-----
 

                      Martin W Sachs

                                               To:
ebxml-cppa@lists.oasis-open.org

                      10/02/2002 11:29         cc:

                      AM                       From:     Martin W
Sachs/Watson/IBM@IBMUS

                                               Subject:  "IMPLIED"
keyword

 

 

 




We may have a problem with the use of the IMPLIED keyword to describe
attribute values in the text.  I ran into a specific case (below) which
makes me wonder whether it is correct to talk about IMPLIED for
attributes
when the validating document is a schema rather than a DTD. Is there any
way of expressing the equivalent of IMPLIED in a schema?

The specific case is the invocationLimit and concurrentConversations
attributes of the ConversationConstraints element of the CPA.  The text
in
section 9.5 is "an IMPLIED invocationLimit attribute" and "an IMPLIED
conversationConstraints attribute".

The CPPA Schema states:
      <attribute name="invocationLimit" type="int"/>
      <attribute name="concurrentConversations" type="int"/>

Since both minOccurs and maxOccurs default to the value "1", it seems to
me
that these attributes are both REQUIRED, with no default stated.

If I am right, someone should go through the text, check for any
attributes
described as IMPLIED, and correct the text to conform to the Schema.

Regards,
Marty



************************************************************************
*************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
************************************************************************
*************



----------------------------------------------------------------
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