[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX and delayed entity loading
At 01:42 PM 12/3/98 -0500, Simon St.Laurent wrote: >>1. href provides no indirection mechanism... >>By concentrating the mapping of local names to storage objects >>in the document prolog, processors (and authors) do not need to scan an >>entire document to know what the doc-to-entity dependencies are. For small >>docs this doesn't really matter, but for very large docs, this can be a >>significant savings. >>... > >Inline hrefs can't do this directly, but similar functionality and >management can be provided through XLink, using hub documents to provide >links rather than keeping all links inline. I don't see how this follows: XLink provides *no* indirection mechanism other than extended links, which wouldn't really do what you need anyway, I don't think (remember David's caution not to confuse storage organization with linking--they are two fundamentally different things and confating them will lead to pain). If you were talking HyTime, we'd be in 100% agreement (except that I'd still use entity declarations in the Hub document, but I wouldn't use them anywhere else). >>2. Notations provide a richer degree of data type specification that is >>more flexible and more generally applicable than MIME types... > >Perhaps, if you're creating your own notations on a regular basis. Which I am. That's the whole point. Remember, it's not just about things like graphics formats, but about application-specific semantic things like queries, like grove constructors for private data types, like arbitrary application-specific data types. MIME >types are quite flexible, however, especially if you don't mind declaring >them as x-whatever. But I do mind: if I see "x-whatever/whatever", how do I know where to look, as a programmer or document recipient, to understand what the rules for that MIME type are? If there's a place, tell me, because either I've terribly misunderstood the MIME mechanism (quite possible) or I've overlooked some non-obvious aspect of x-* MIME types. >Web. It may be worthwhile for users who do need to keep all that >information in the document, and therefore worth keeping, but... what a >headache... It's not a headache if you have a document-centric system where you are not dependent on software or the protocol of the day to define your data dependencies. I have clients with documents with expected life spans measured in hundreds of years. Will recommend that they rely on MIME types? Not under any circumstances. Not to say that MIME types are bad, only that I don't expect them to be around in 100 years. I do expect SGML and XML, as *implementation and system independent standards* to be around in 100 years. >XML is SGML simplified enough to be useful to a wider audience, but there >are many times I wish it had been simplified considerably further. (That >way, when we go to add all these new features, they aren't all redundant, >among other things.) Notations are not redundant with MIME types for the very important reason that mapping of short name (notation name, MIME type name) to definition is managed using SGML/XML-defined means for notations and by other means for MIME types. (Which means, in part, that you get to choose your own local names for notations, which you of course cannot for MIME types.) Note also that if the external ID for a notation *is* a MIME type (or its defining RFC), then notations can take advantage of the MIME infrastructure, which is probably useful. Notations are more general than MIME types, so MIME cannot completely replace the use of notations. It's also important to remember that XML is not designed to work *only* on the Web, it is designed to work *well* on the Web. It would be foolish at best to design a language that only had those things absolutely needed by today's Web technology. It would be like designing roads that can only accomodate model T's because that's all people have today. If you don't find notations useful, don't use them in your documents. 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
|