RE: !BEHAVIOR

>At 10:39 11/6/97 -0700, Andrew Layman wrote:
>The example that was being discussed, <date>19960527</date>, clearly showed
>that what is important is knowing what something is. Unless you understand
>the notation used for this date you cannot interpret it. As I said in my
>earlier messages, as we cannot use notation for XML elements, and we do not
>have access to the lexical typing mechanism provided in the SGML Extended
>Facilities Annex, we need some way to distinguish between the following
>valid dates:
>
><date country=US>01022001</date>
><date country=UK>01022001</date> (30 days later!)
><date country=Isreal culture=Hebrew>20010101</date> (This isn't even in the
>same millenium!)
><date country=Isreal culture=Arabic>10022010</date>(This  isn't the same as
>any of the other dates.)

In tradtional SGML, we use attributes and depend on applications to
interpret them. We don't have a standard way to do this (which means that
you may have to write date-checking code to verify your conforming SGML
documents).

Leaving things like this is _not_ a showstopper flaw. Most stylesheets need
not know the data type of element contents, and most applications that do
will require much more structure than a single element, and will use the
doctype anyway (though they may have the DTD (and other data formats)
compiled in).

><date>01022001</date> is clearly not sufficient to undertand the contents.
>You need some qualifier (as I have been forced to do with application
>specific attributes in the preceding examples).

And it's not something that we desperately need, but something that we
would like for some applications.

>There are many other cases where you need to invoke some outside interpreter
>to be able to understand what an element represents.
exactly, and currently it's a processing decision -- if you're not doing
_any_ procressing, then syntactic restrictions on the values don't really
matter.

>Either you need a
>notation processor as per SGML or you need some other indirectable mechanism
>for identifying how to interpret the data.
stylesheet.

>What I was suggesting was that
>this should be done with a standardized attribute, which I called behaviour
>for want of a better name. I do not believe this is about presentation, it
>is about being able to make sense of the data when it is not in the same
>textual format as the rest of the document. Its about understanding what
>something actually is.

Sounds like a great idea for a set of architectural forms that might be
used by people with similar problems.

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 11 June 1997 21:19:17 UTC