SPUG: XML::Parser empty vs. "empty" tags

[Ryan Parr]

> The technique advocated here is to use an attribute, such as <tag
> null="true"/> to represent null values.  I had thought of that, of
> course.  The reason I don't
> like this approach is that it makes possible constructions which are
> semantically ambiguous and/or contradictory:
>
> <tag null="true">some text</tag>
>
> How should my application deal with this?  The attribute says that
> the tag is null, but there's some text inside.  Should it ignore the
> text and treat the tag as null (semantically equivalent to <tag
> null="true"/> )?  Should it accept the text and ignore the "null"
> attribute?  Should it consider such a construction illegal?  How
> should it enforce this rule?

You could simply *allow* the tag to be null, but not enforce it. If the tag
contains text, then it's not null. If it doesn't then it is. There must
certainly exist cases where the outputting application would need to put
text into a tag that is usually null, otherwise you would always know what
the null tags are going to be, and be able to deal accordingly.

On the other hand, if the outputting application will know when a tag is
null to output <tag /> or when it should be an empty string as <tag></tag>
then the ambiguous constructs could safely be ignored, and you could always
treat <tag null="true">blah</tag> as a null. If there exists possible issues
with expecting the application to always be right, then you would experience
the same issue no matter how you do it.

This extent of extra effort does, though, raise a question about the need
for a difference between an empty string and a null value.

-- Ryan Parr


-----Original Message-----
From: owner-spug-list at pm.org [mailto:owner-spug-list at pm.org]On Behalf Of
Jason Lamport
Sent: Saturday, September 15, 2001 9:39 PM
To: Seattle Perl Users Group
Subject: Re: SPUG: XML::Parser empty vs. "empty" tags


At 7:58 PM -0700 9/15/01, Colin Meyer wrote:
>
>Simple answer: no.  <tag></tag> and <tag /> are semantically equivalent
>according to the xml standard.

Hmmm... do you (or anyone else following this thread) have a
reference for where in the XML standard it says that <tag></tag> and
<tag /> are semantically equivalent?  That seems like the sort of
thing that would be left up to the particular application.  I don't
recall the issue ever being mentioned in the O'Reilly book (which is
where I generally go for my information on XML).

At 7:54 PM -0700 9/15/01, James Moore wrote:
>I won't claim to be an XML expert, but what you're saying doesn't
>really fit with what I know.  My understanding is that the two cases
>are supposed to be identical, and trying to distinguish between the
>two isn't the right way to go.  Putting "xml represent null value"
>into Google came up with lots of hits, the most promising of which
>seemed to be (after only a few seconds of reading, so I could easily
>be off base):
>
>http://www.adodb.com/xml_result.asp?xml_id=32
>

The technique advocated here is to use an attribute, such as <tag
null="true"/> to represent null values.  I had thought of that, of
course.  The reason I don't
like this approach is that it makes possible constructions which are
semantically ambiguous and/or contradictory:

<tag null="true">some text</tag>

How should my application deal with this?  The attribute says that
the tag is null, but there's some text inside.  Should it ignore the
text and treat the tag as null (semantically equivalent to <tag
null="true"/> )?  Should it accept the text and ignore the "null"
attribute?  Should it consider such a construction illegal?  How
should it enforce this rule?

I would prefer to use my approach because it makes these
contradictory cases syntactically impossible.

-jason

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/




 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/