xml-dev - Re: Notations

[Joel Bender <joel@spooky.emcs.cornell.edu>]

Just as I thought my mind was clear, it gets muddy again.

John Cowan <cowan@locke.ccil.org> wrote:

    >> The path to the handler probably belongs in a system
    >> dependent application config file, not the DTD.  Much like
    >> how web servers use config files to look up MIME handlers.
    >
    >  Exactly so!

>From this I get the impression that the DTD contains a NOTATION that refers
to some specification of content, i.e., image/jpeg.  This does not provide
a mechanism to describe how it is encoded, you need a content transfer
encoding description as well.  It does at least tell you that the content
is a picture and that its jpeg encoded.

W. Eliot Kimber <eliot@dns.isogen.com> wrote:

    >  Remember that notations do not affect the *parsing* of the
    >  data, only its semantic interpretation.

Humm.  This gives me the impression that a notation doesn't say how the
contents are encoded, only that its a 'picture'.  This is fine for some
applications like the web that don't need or want to specify anything in
more detail (i.e., the <logo> contents can be any kind of picture).  But
this isn't enough for some applications.

As quoted by David Brownell, Lars Marius Garshol wrote:

    >  Well, you can't very well transmit the data model itself
    >  between computers or down through time.  In other words:
    >  you must have the serialization syntax.  The question is:
    >  is an explicit specification of the data model of any use?

In my application environment it is abosolutly necessary, and the role of
the standards process.  With "wiggle room" it is too easy for systems to
fall out of interoperability, usually at the expense of the receiver, since
the transmitter could point the to standard and say "See, it says I can
send you any encoding I want and its up to you to support that encoding,
therefore I am still in compliance."

To continue with my analogy <box><width>30</width></box>, I must be able to
say that the contents will be a decimal encoded integer.  Not hex, octal,
bit string, base64 encoded, etc.  Perhaps more encoding formats will be
supported in the future, at which point all parties will be given the
opportunity to state their compliance to the new standard.  In some cases
the specification will provide a minimum and maximum range, so applications
know what to expect, but I don't care if your system uses long or short
integers, etc., or what mechanism you use to figure out how to
encode/decode the contents, we call that "a local matter".

Len Bullard <cbullard@hiwaay.net> wrote:

    >  I spent the day creating a DTD for a language in which the
    >  original grammar has very explicitly defined datatypes.  I
    >  stuck CDATA everywhere and am not very [happy] about that.

It sounds like notations are what I (we?) want to use, its just that the
supporting documentation the notation refers to will be stricter than what
is required in other application domains.  It would also be nice if the
notation id could refer to a specific section of a document, so all of the
foundation types (I guess I shouldn't use the word "atomic") are collected
into a single, easily versionable, document.


Joel

p.s. - if you would like to know about my application domain, visit
<http://www.BACnet.org/>.

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