Lists Home |
Date Index |
- From: "Jonathan A. Borden" <email@example.com>
- To: "XML Developers' List" <firstname.lastname@example.org>
- Date: Wed, 30 Sep 1998 14:01:35 -0400
> > Yeah, but NOTATIONs require the use of a validating processor, and
> > lots of non-validating apps would like to use base64. Having said
> > that, I think that your proposed xml:content is more or less exactly
> > what NOTATION is for? -Tim
> Yes, it was intended as a lighter-weight alternative to the use of
> NOTATION attributes.
The proposed xml:content attribute does serve as a lightweight alternative
If xml:content values are MIME types, this is a simple alternative to FPI's
etc. In the same way that people don't wish to be forced into the use of a
DTD, we have a similar need to label types without FPIs (it is apparent from
a parallel thread that the whole idea of FPI namespaces is likely to
engender heated debate for some time). MIME types while not perfect, have
practical and widespread use. When used with xml:packed="base64" the default
is xml:content="application/octet-stream". When xml:packed="none" the
default is xml:content="text/plain". Is there a good way to specify this?
We have had discussions about why XML isn't as widespread as it might be.
The conclusion of some was that things are getting bogged down in needless
complexity. If most of HTML is going to be replaced by XML (and there is no
reason that this might not happen), then these issues need to be solved in a
simple and lightweight fashion.
JABR Technology Corporation
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)