xml-dev - Notations [Murray Altheim]

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

Peter Murray-Rust <peter@ursus.demon.co.uk> writes:
> At 15:36 25/06/98 -0400, John Cowan wrote:
> [...]
> >Perhaps there should be a convention mapping MIME types onto XML
> >notation names.  Of course, the "/" in MIME types isn't an XML
> >name character, so it would have to be mapped into something else.

I'd imagine whatever syntax we chose, the actual MIME reference would 
be inside of a literal, so I don't think the slash character is an issue.
Notations could be identified by MIME type, but that would limit the 
available notations to existing MIME types, and that certainly would be
a mistake.
 
> Without really knowing anything about NOTATION this seems a good idea.
> Whenever I ask "why can't we have MIME support in XML?" (e.g. for an HREF
> target) I am told by the gurus that NOTATION should be used. If there is an
> algorithmic mapping, then I can use MIME and it can be converted into
> NOTATION...

I agree in part. NOTATION declarations are used to assign a unique name to
the notation, language or format of an external entity. GIF, Java, ActiveX,
ECMAScript, etc. all come to mind as descriptors of something that might be
typical notations used in XML documents. As an example, our Sun version of 
DocBook (SolBook) declares twenty-six notations. Any time an non-SGML 
external entity is declared in a SolBook document, the declaration includes
a reference to a previously-declared notation, such as

   <!NOTATION GIF89a PUBLIC 
       "-//CompuServe//NOTATION Graphics Interchange Format 89a//EN">
   [...]
   <!ENTITY fig3 SYSTEM "figure3.gif" NDATA GIF89a >

Declaring and referencing an entity with a GIF89a notation then infers that 
a processor is available which understands the GIF89a notation. Linking this
processor with the document requires some link between the notation name,
the processor and the entity. In Arbortext's AdeptEditor, in HTML browsers,
etc. this is all hardwired. We can't rely on hardwired notations like we
did in HTML.

What we need is not only a way to label the notation of an external
entity (which we have), but also a standard syntax that can associate an
external processor and/or any other necessary processing infrastructure 
inferred by the notation. This is metadata, not part of the document content
itself.

If we attempted to architect this with common SGML principles, we'd try to
separate this processing-specific information (both the processor and
any processing instructions, ie., scripts) from the document content in 
order to keep the content portable and not bound by specific processing 
requirements. Or at very least, authors should have that option.

    A 'Simple' Scenario
    
    1. declare a notation
    2. upon referencing an entity with that non-XML notation, link
       the notation of the entity with the declared notation to
       retrieve the URI of the processor.
    3. check your cache of processors. If you don't have a
       processor for this notation, retrieve one via the notation URI.
    4. load the processor and feed it the entity URI.
    5. sit back and enjoy the fireworks

The processor could be on the plug-in model. Anytime your application
came upon an unknown notation, it would download the plug-in to handle
that notation. There's a bit of a hitch though, as the XML spec does 
not require that the notation declaration actually reference a processor;
it may simply reference a description of the notation. The purpose of
the notation declaration isn't really to link a processor but simply
declare the notation. We'd need to either modify this by making clearer
the processing expectations inferred by a notation declaration, or come 
up with new syntax that performed this task. I'd suggest the latter.

We need a combination of Xlink (to perform the physical link) and RDF
(which provides the basic associative model). Notation declarations on
their own can't be relied upon as currently specified, and we certainly
can't require or even allow application-hardwired notations to become 
the norm unless we're willing to settle back into the HTML browser world.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey         <mailto:altheim&#64;eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900
         "Give a monkey the tools and he'll build a typewriter."


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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)