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

Re: Unspecified #IMPLIED attributes in Java

• From: Toby Speight <tms@a...>
• To: "XML developers' list" <xml-dev@i...>
• Date: 19 Dec 1997 15:31:40 +0000

Mark> Mark L. Fussell <URL:mailto:fussellm@a...>

> In article <Pine.SOL.3.91.971219062223.1470B-100000@alumnae>, Mark
> wrote:

Mark> On 18 Dec 1997, Toby Speight wrote:
>> ... DSSSL's attribute-string function returns #f for [unspecified
>> #IMPLIED attributes]; 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/>.

Mark> I certainly agree that it is useful to tell the difference
Mark> between these two cases, but it does bring up the issue that
Mark> Peter said: do all users understand the issue?

That's up to the application program.  I have no problem with programs
that treat the two examples the same *provided their documentation
says that's what they are doing* (though I'd be more likely to declare
the default value to be the empty string in the DTD).  In DSSSL, this
behaviour would be

 (let ((val (attribute-string "bargh")))
   (if val
       val
     ""))


Mark> Also, null can only be used for 'notSpecified' if null is not an
Mark> acceptable value.  Frequently it is, so it is better to have a
Mark> seperate 'notSpecified' marker or attribute.

Are we talking about the same thing here?  If the parser returns a
string for each attribute value, then the Java null reference is
distinct from any acceptable (i.e. writable in the XML document)
value.  You've confused me with your suggestion that null may be an
acceptable value; would you care to clarify?


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

Mark> Standardizing on a particular interpretation is unfortunately
Mark> much more difficult. ...  The problem is that there are many
Mark> possible and useful interpretations of "missing information":
Mark> ...

I realise this; I was merely attempting to describe what #IMPLIED is
used for in practice, with specific application[*] conventions -
that's why I used the word "often" ;-).

[*] using the word "application" in its SGML sense - argh!

Mark> But it can be convenient to not be so "wordy".  In which case the
Mark> application will have to be very explicit and consistent about what
Mark> 'notSpecified' means (and, for XML, how that relates to #IMPLIED when
Mark> there is a DTD).

Agreed.

Mark> For MONDO, this can be very consistent because 'notSpecified' and
Mark> #IMPLIED are both treated exactly equivalent to the parameter not
Mark> existing.  But other applications may have difficulty with this.

I've been looking at it the other way around - to me, it seemed "obvious"
to return #IMPLIED as null, and then to think about whether the no-DTD
case is equivalent.  [I think that that bias springs from the fact that I
haven't written any DTD-less applications and I generally use traditional
SGML tools (SP, Jade, psgml-mode, etc.).]

FWIW, I concur that DTD-less processing ought to be equivalent to
specifying all attributes as #IMPLIED, but for the parser API, there
is a difference: I think that the parser should return null in the
valid-processing case, but in the well-formed DTD-less case, it cannot
know that the attribute has been omitted, and so will return neither
the name nor the value of the attribute.

If I write a {grove, tree} builder, it would be useful to know whether
a DTD was used, so that it can report an error to an application trying
to access an attribute that was not declared (this may be the symptom
of a typo, perhaps).  If a DTD was not used for the parse, then the
access should return null (as if the attribute were declared #IMPLIED).



-- 

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: Paul Prescod <papresco@t...>

• References:
  • Re: Unspecified #IMPLIED attributes in Java (was: Goals: XML ...)
    • From: "Mark L. Fussell" <fussellm@a...>

• Prev by Date: Re: RFC: Simple XML Event-Based API for Java
• 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