Re: Public IDs for notations in XML

Eliot writes:
| Notation declarations consist of a notation name followed by an external
| identifier.  The external identifier consists of either the keyword
| "SYSTEM" followed by a literal containing a MIME type specification or the
| keyword "PUBLIC" followed by a literal containing a public identifier
| followed by a literal containing a MIME type specification.

Executive summary:  you don't need either.

If the "MIME type specification" is a registered MIME type, then
PUBLIC is appropriate.  If not, SYSTEM is.  But really, you
shouldn't need either so long as you say that notation declarations
must be MIME types:

<!notation jaypeg "image/jpeg">
<!notation mypeg "x-mypeg">

are equally comprehensible and both values are completely ready to 
be passed to the application that takes the output of the XML parser.

| Thus, a notation declaration could either be:
| <!NOTATION Graphic PUBLIC "-//Joint Photographic Experts Group//NOTATION
| JPEG Image Format//EN" "image/jpeg" >
| or 
| <!NOTATION Graphic SYSTEM "image/jpeg" >

or, as noted, 

<!NOTATION Graphic "image/jpeg" >

| If XML does not specify a public identifier resolution mechanism then it
| would not be allowed to have a public identifier without a corresponding
| MIME type.  If there is such a mechanism, then it would be possible,
| potentially, to do the mapping to MIME types there.

?  MIME types are registered at a well known place.  No pointer is
required if they are registered; if not, local knowledge is required
anyway, and it is required by applications outside the XML parser, not
within the process of parsing XML.
 
How do you set up a new unregistered MIME type in browsers now?  Not
with a URL in the HTML document that uses the unregistered MIME type,
but by feeding the appropriate information to the (supra-HTML) browser 
application.  What would you expect to obtain by resolving a URL
anyway?  a description of a MIME type in term of other MIME types?
an applet that automatically plugs itself into your browser and
registers itself locally with any arbitrary XML user agent?

| One reason for allowing the public identifier for notations without a
| resolution mechanism is to make the correlation between existing notations
| used in SGML documents and the MIME types used for Internet delivery
| clearer, especially to those who already have SGML documents.  Obviously,
| if you are coming from HTML and only ever thought about MIME types, you
| don't necessarily need or want a public ID and don't need to specify one.  

If the reason for allowing something is educational, get rid of it.
Your needs are the same regardless of your background.  If you don't
need to specify something, then you don't need to specify it.
 
| In addition, many SGML processes (including much of architecture
| processing) depend on notations and public identifiers for notations, so it
| will make taking advantage of these facilities from XML much easier if we
| allow public identifiers for notations even if we don't for entities.  

The need for public identifiers is obviated if you use MIME types,
which are by definition labels for well known semantics.  And like
URNs, the semantics for MIME types must be resolvable outside
of HTML user agents, so you might as well avoid creating an XML-specific
way of pointing at MIME semantics.

Lee responded to Eliot:

| I think this is very sensible, although I would urge a list:
|     <!NOTATION Graphic SYSTEM "image/jpeg,image/gif,image/png">
| 
| This would allow for content negotiation in an interesting and clean way.

Content negotiation is a completely separate layer of the Internet
architecture.  Notation declarations (in an XML DTD) should not
be bound to the preferences of any particular user agent.

| It would mean
|     I like jpeg no less than gif (and maybe a lot more)
|     and I like gif no less than I like png,
|     so send me the image in the first matching format in this
|     list that you can, please.

This is backwards.  The user agent cannot express its preferences
through the preestablished markup of a document it receives!


Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Friday, 13 December 1996 22:13:18 UTC