[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Unspecified #IMPLIED attributes in Java (was: Goals: XML ...)

• From: "Mark L. Fussell" <fussellm@a...>
• To: Toby Speight <tms@a...>
• Date: Fri, 19 Dec 1997 06:51:24 -0800 (PST)

On 18 Dec 1997, Toby Speight wrote:
> David has answered the original question (what is isSpecified() for in the
> Java simple API?), but I thought I'd mention that DSSSL's attribute-string
> function returns #f for PLUGH; the Java equivalent of this is of course,
> null.  I think this is the Right Thing to do; it's sometimes important to
> tell the difference between <Fu bargh=""/> and <Fu/>.

I certainly agree that it is useful to tell the difference between these 
two cases, but it does bring up the issue that Peter said: do all users 
understand the issue?  Also, null can only be used for 'notSpecified' if 
null is not an acceptable value.  Frequently it is, so it is better to 
have a seperate 'notSpecified' marker or attribute.

> The first case is often used to mean a known, empty value; the second
> to mean "not known" or "not applicable".

Standardizing on a particular interpretation is unfortunately much more
difficult.  Relational databases have generally failed at this (SQL is 
broken because of it) and Codd now uses multiple "marks" in his view of 
the Relational model.  The problem is that there are many 
possible and useful interpretations of "missing information": 
   (1) Uninitialized  
   (2) Inapplicable  
   (3) NotYetKnown  
   (4) NotEntered  
   (5) FunctionallyUncomputable 
   (6) OutOfDomainBounds
and so on...  See C.J. Date's writings for good descriptions of the above.

It is always [yes, I believe always] better to be explicit about what is
known (which can include explicitly what is not known) than it is to rely
on a meaning for something that is "missing".  So:
    <... stars="0" >
    <... noStarRating="true" >
are all better than to just leave 'stars' off and imply an application 
meaning.

But it can be convenient to not be so "wordy".  In which case the
application will have to be very explicit and consistent about what
'notSpecified' means (and, for XML, how that relates to #IMPLIED when
there is a DTD).  For MONDO, this can be very consistent because
'notSpecified' and #IMPLIED are both treated exactly equivalent to the
parameter not existing.  But other applications may have difficulty with
this.

But, in general, defaults seem to be easily understood and anything else 
is on the brink of infinite possibilities.

--Mark
mark.fussell@c...

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Unspecified #IMPLIED attributes in Java
    • From: Toby Speight <tms@a...>

• References:
  • Unspecified #IMPLIED attributes in Java (was: Goals: XML ...)
    • From: Toby Speight <tms@a...>

• Prev by Date: Re: XML as a programming tool
• Next by Date: Re: XML as a programming tool
• Previous by thread: Re: Unspecified #IMPLIED attributes in Java (was: Goals: XML ...)
• Next by thread: Re: Unspecified #IMPLIED attributes in Java
• Index(es):
  • Date
  • Thread