OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: <XML:SCRIPT>

[ Lists Home | Date Index | Thread Index ]
  • From: "W. Eliot Kimber" <eliot@isogen.com>
  • To: <xml-dev@ic.ac.uk>
  • Date: Wed, 08 Jul 1998 14:16:27 -0500

At 09:26 AM 7/8/98 -0700, Lisa Rein wrote:
>This is a very interesting question to me, right now, because I am
>currently writing about the Action Sheets modularized scripting for HTML
>and XML proposal (paraphrase on purpose) from Netscape, and I'm having
>trouble swallowing this (from the spec)  can anyone help me to
>understand if this is true or maybe how it was meant to be taken (and
>yes I've tried the Netscape guys first....)
>
>> While HTML contains a SCRIPT element and HTML
>> elements may contain attributes that specify event handlers (onClick,
onMouseOver, etc.), XML
>> contains no way of including an external scripting language. 

This is not true. You can include any kind of data in an XML document,
including scripting languages. What there is not is a standard or
convention for interpreting any particular script language. But XML gives
you everything you need to *declare* the script you're using sufficient to
allow processing programs to recognize the fact of script use and do
whatever it is they do.

This is what notations are for (unfortunately, by choosing not to include
data attributes, XML has severely limited the utility of the notation
feature, but I'm sure that will be corrected).

For example, say I want to include JavaScript in my XML documents (not that
I would, but let's pretend).

I would first declare a notation to represent JavaScript:

<?XML version="1.0"?>
<!DOCTYPE MyDoc [
  <!NOTATION JavaScript PUBLIC "+//IDN netscape.com//NOTATION Java
Script//EN" >
...
]>
...

This serves to connect the local name "JavaScript" to the formal
specification that can presumably be found at the other end of the public
identifier for the notation. By definition, the external ID for a notation
is supposed to get you the human-readable definition of the notation. You
might also use the external ID as a way to select the appropriate
processing code, such as to choose a plug-in to process the data.  This is
the way my PHyLIS HyTime engine is implemented (see <http://www.phylis.com>).

I can now use this notation with an element so that processors will know
that the notation governs the interpretation of the element:

<?XML version="1.0"?>
<!DOCTYPE MyDoc [
  <!NOTATION JavaScript PUBLIC "+//IDN netscape.com//NOTATION Java
Script//EN" >
<!-- Script element contains JavaScript code: -->
<!ELEMENT Script 
  (#PCDATA)
>
<!ATTLIST Script
   notation
     NOTATION
     (JavaScript) JavaScript
>
...
]>
<MyDoc>
 <Script>This is a JavaScript script</Script>
</MyDoc>

When this document is processed, a processor can see that there is a
notation attribute (that is an, attribute whose data type is "NOTATION"; by
convention we normally use the attribute name "notation" as well, but
that's not required).  It knows by the rules of XML/SGML that the named
notation governs the interpretation of the element.  It looks up the
notation information and sees the external ID for JavaScript (it must key
off the external ID because the notation name JavaScript is a local name
and could be anything--you can't depend on authors using the string
"JavaScript", even though most will).  

It sees that there is a dll function or plug in or module or COM object or
JavaBean associated with that name and passes the element to it (presumably
a pointer to the in-memory representation of the element, or possibly the
string representation of the element, depending on the nature of the
processor). The notation processor then does whatever it does and comes
back, returning whatever the interface between the main processor and the
notation processor requires or allows.

This is essentially what you do to process objects with different MIME
types. The only difference is that notation types are not pre-defined or
necessarily registered anywhere because notations are a more general
facility than MIME types. You can associate notations with individual
elements or with individual attributes (the HyTime standard uses this
technique to associate governing notations with attributes that specify
addresses in notations not defined by HyTime, see the "reference location
type" facility,
<http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-7.8.html>).

Any browser vendor could define a fixed set of notations that it
recognizes, defining what external identifiers it will recognize and what
the rules are for use of that notation. But it would be better to provide a
more general integration facility of which built-in things are an instance,
rather than the only choice.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS