[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX and delayed entity loading
At 06:57 PM 12/3/98 -0500, Chris Maden wrote: >MIME types or notations eventually come down to a magic word of some >sort. MIME types work now; notations don't yet. > >I want a notation to make it *go*, not tell me what to read to make >something to make it go. Since we're not all using the same >programming language, magic cookies are the only workable solution; >MIME combines this with robust, well-defined fallback behavior. Let's try this code from my PHyLIS tool, which associates grove constructor objects (COM objects in this case, because I'm implementing on Windows), with the external IDs for the notations those grove constructors support. A grove constructor is a software component that takes an entity (or another grove or subgrove) as input and constructs a grove from it. Grove constructors are associated with the notations they understand. PHyLIS, as a generalized tool, lets you create and plug in grove constructors for any data content notation. An entry from the configuration file for PHyLIS looks like this: <grovecon> <!-- Configure a single grove constructor --> <COM-progid>PHyLISlib.SPSGMLGC</COM-progid> <!-- Implementing software component --> <notation-extid>sgml</notation-extid> <!-- External IDs of notations this GC understands --> <notation-extid>SGML</notation-extid> <notation-extid>ISO 8879:1986//NOTATION Standard Generalized Markup Language//EN</notation-extid> </grovecon> The code below reads the configuration and sets up a table that maps the notation external IDs to the grove constructor software object. This is, as far as I can tell, just what you do with MIME types. I could, in fact, I suppose, support the association of grove constructors with MIME types as well (I get that for free if they are used as notation external IDs). Note that this dependence on notations (and, by implication, entity declarations) doesn't preclude doing MIME-only based association of resources addressed by means other than entity with grove constructors, but that's not how the HyTime standard is currently defined (nor, I think, should it be). When I create an XLink-only version of PHyLIS, of course I'll have to do that (because it will still be grove based, of course). ' At this point, we've parsed the configuration doc and found a grovecon element. This ' bit is in a loop that iterates over the grovecon elements. Set gcelem = PHyLISlib.child_of_type(workelem, "grovecon") ' gcelem is grovecon element Do While Not gcelem Is Nothing Set workelem = PHyLISlib.element_child(gcelem, 1) ' workelem should be COM-progid elem If Not workelem Is Nothing Then With mobjGroveManager If workelem.Gi = "COM-progid" Then progid = PHyLISlib.Data(workelem) Set workgc = mobjGroveManager.CreateGroveCon(progid) ' Instantiate the object If Err.Number <> 0 Then MsgBox "Error: Unable to create grove constructor object." Else ' At this point, workelem is COM-progid Set workelem = PHyLISlib.next_element_sibling(workelem) Do While Not workelem Is Nothing If workelem.Gi = "notation-extid" Then extid = PHyLISlib.Data(workelem) '------------------ ' !!! HERE IT IS: '------------------ mobjGroveManager.RegisterGroveCon workgc, extid ' This function adds an entry to table that lets you look up the ' grove constructor by notation external ID. End If Set workelem = PHyLISlib.next_element_sibling(workelem) Loop End If End If End With End If Set gcelem = PHyLISlib.next_element_sibling(gcelem) Loop This is a system that provides completely generalized support for associating notations with notation-specific processors. The same technique is used to bind processors for other types of notations (query notations, storage manager notations, property sets, viewable object notations, etc.). I haven't implemented support for superclass notations (for fallback), but I plan to. My plan is to have PHyLIS prompt for user intervention when it encounters a notation for which it doesn't have an available component. You should be able to find and download a grove structor (should one exist) or renderer for a particular property set, plug in, add it to the mapping table, and off you go. This is no different from following a link to a resource for which you have no renderer or plug-in available (or correctly registered on your machine) and having to figure out what to do about it (I was always having this problem with VRML--now I have the opposite problem, IE5B2 thinks all .gz files are VRML worlds--I had to disabuse it of that notion right away, unfortunately, it took a rather heavy blow to do it). I ship PHyLIS with a default configuration, of course, just as your Web browser comes with a default set of MIME-to-object mappings. If all you need is what PHyLIS provides out of the box, you'll never have to worry about it, just as with Web browsers. But if someone gives you a document with a unqiue notation, they better also provide you with the necessary constructors and renderers, or it's just a text file--but that's always the case. The use or non-use of notations or MIME types can't change that. All that notations or MIME types are about is providing a way that reasonably persistent names for things can have some reasonably intelligble mapping to a definition of what they are so that tools like PHyLIS and Web browsers and the users of those tools have some hope of configuring things correctly. But they aren't magic--they don't remove the need for humans, usually users of individual computers, to keep their systems configured appropriately and they can't eliminate the problem of getting data that your system doesn't yet know how to deal with it. That's why, in the end, it always comes back to documentation for humans--at some point some human has to know that "foo" means "this kind of data" and has to know that on their system at that point in time, software component X is the appropriate tool to use on that data. Nothing about MIME or notations can change this. 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|