Notations

[Charles Reitzel]

Joel Bender wrote:
>James Robertson wrote:
>> XML isn't a solution to any problem, it is a storage and
>> interchange format for applications ...
>
>Well, in a sense, yes.  All of the interchange formats that 
>I've delt with (we call them protocols :-), don't stop at the 
>structure of the message but also specify what is acceptable content.

Yes.  For concrete examples, see the Financial Information Exchange (FIX)
protocol at www.fixprotocol.org.  Also, read about the UN/EDIFACT EDI
message formats at www.disa.org.  These are electronic commerce protocols in
use by thousands of companies to execute billions in trade (these numbers
are chump change when compared to relational database).  Both provide for
the basic data types: string(N), number(M.N), date/time.  Both have had
stated plans to migrate to XML for over a year now.  Neither has done
anything (at least not publicly) to this end in many months.  IMHO, without
a concise method of associating a data type with element and attribute
values, they are better off without XML.


Joel Bender wrote:
>
>Simon St.Laurent wrote:
>> >> How would I apply a MIME type to an attribute?  More important,
>> >> why one earth would I want to?  Seems like some pretty heavy
>> >> overkill.
>> >
>> >To say what the internal syntax of the attribute value is.
>>
>> Er, yes, that's overkill, like I said.  Nuclear weapons to kill
>> gnats and all that.
>
>I don't think its overkill, all I want is a nice formal mechanism 
>for saying my WIDTH attribute of my BOX element is an integer.  If 
>a schema can do that, cool.  If a notation can refer to a schema 
>and support mime types along with it, fine.  Whatever mechanism 
>should be able to support patterns like those that appear in the 
>XML 1.0 spec, which is not complicated.  If there are rules that 
>allow the translation of correctly matching content to atomic data 
>in the DOM, even better.  In my mind, MIME types can do this for some 
>types of data but doesn't have simple atomic types defined, 
>i.e., text/integer.

Well put, Joel.  Notations appear to me to be the best way to declare the
atomic types.  I humbly submit that a well designed schema would include a
set of notation declarations for its atomic types and perhaps a few middling
complex types.  In XML, there is no way to associate an attribute value with
a Notation.  Attributes can contain notation names for use in describing the
element value.  It is up to the application, however, to interpret the
attribute name and value as descriptive of the element.  According to Eliot
K., some variant of SGML allows notations to be associated with attributes.

Using:
<!NOTATION Iso8601_DateTime 
        PUBLIC "whatever you need to signify YYYYMMDD-T235959" >

<!NOTATION OrderNumCol
        PUBLIC "a reference into your schema or whatever you like" >

I would like to see the following syntax:
<!ELEMENT OrderTime (#PCDATA) NDATA Iso8601_DateTime >

Attribute Notations might look like:
<!ELEMENT Order (#PCDATA, OrderItem+) >
<!ATTLIST Order
        <!-- ... -->
        TimeStamp NDATA Iso8601_DateTime CDATA #REQUIRED
        OrderNum  NDATA OrderNumCol ID #REQUIRED
        <!-- ... -->
>

Some notes:

- The ability to associate Notations with attributes would have major
advantages for mapping SQL data.  This is because XPointer works well with
attributes.  Thus you can have well defined values *and* support compound keys.

- Notation parameters would help a lot to map to real back end systems.
E.g. "NDATA Integer(MaxDigits,4)" or "NDATA Float(Precision,10,Scale,4)" or
"NDATA AlphaNum(MaxChars,12)".  Whatever happened to "the easy stuff should
be easy, the hard possible"?  Working with basic data types should be easy!

- For myself, I think of Notations more as logical data descriptions than as
a method of finding an executable program to run.  Given that XML element
and attribute values are text, a Notation denotes how to transform the
"native" data to and from text.  As with MIME, implementations will vary.

- A nice thing about Notation syntax is that it is all but transparent to
non-validating parsers.  The data may still be meaningful and useful for
many purposes without interpreting Notations.

- Notations might be useful in style sheets.  E.g. render elements notated
as "Float" a certain way.

- Data types do not need standardization in XML - just the method of
defining them.  This would let the various groups defining standard business
data types for XML work with a common syntax and avoid duplication of effort.

====================================================

A number of people have pointed out the benefits of deferring to existing
MIME handlers for composite documents.  Their arguments are convincing for
composite documents.  They are have little or no bearing on e-commerce
applications.  No one is trying to force the use of Notations anywhere.
Just don't dismiss them because you aren't using them.

There have been a couple real good suggestions: 1) a generic MIME notation
used to defer to a MIME content handler and 2) when you know the content
type, use a NOTATION for each mime type per John Cowan.  There are many good
approaches.  The best in any given case depends on the application requirements.

Regards,
Charles Reitzel
creitzel at mediaone.net


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