NOTATION/MIME (was Re: Recent XML WG decisions)

Chris Maden crism at
Mon Sep 15 17:02:22 BST 1997

[Rick Jelliffe]
> [Peter Murray-Rust]
> > Being picky, this is not valid XML since prod [74] requires a
> > SystemLiteral as well as the PubidLiteral.
> Yep.  And do the < and > have to be entity references too in XML?
> Yep, XML does not support "formal" system identifiers as I
> understand it.  I think it is a shame, since there are things that
> are not URLs that would be nice as identifiers, even in web systems.
> But support for FSIs can be retrofitted at some later stage to XML.
> I hope there is no chance of them being added to XML 1.0.  But I
> hope people keep FSIs in mind as a good way to ramp up the power of
> URIs and other identifiers in the near future, in particular for
> selecting particular system identifier notations (schemas).

FSIs were discussed at the beginning.  A decision was made that they
were better left for later, and I agree.

A decision was also made that all system identifiers would have an
implicit FSI identifier of <URL>, which I also think is usually a good
idea.  This allows FSIs to be added later, and any unlabeled system ID
is implied to have <URL>.

What I was suggesting on the SIG was that for system identifiers in
notation declarations, the assumed FSI label would be <mimetype>.  As
Rick pointed out, this is legal HyTime 2 FSI notation, and would be
very useful.  However, the WG has made its decision.

I believe that XML authors are largely going to refer to images simply
by URLs instead of entities; in that case, file system associations or
HTTP headers can be used to ascertain the entity's type.  In cases
where NDATA entities are used, I would recommend that XML implementors
ignore the system identifier of the notation, and make their decision
based on the entity itself.

<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL> <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list