[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Process vs. Markup (was Names, Dates, Etc.)
John Cowan wrote: > For all of these, we need architectures rather than markup languages > per se, because applications may need more than one name, date, > or money amount. This discussion now has nowhere to go without first sorting out the various stages of markup and processing. XML is being promoted--aggressively--as freedom for every Web author to express each nuance of personal epistemology by creating new tags, by following individual preferences in attributes vs. elements, and by constructing uniquely rococo subelement structures. That is the promise which has lured the customers in from the HTML world (the masses are not coming to XML from SGML). Namespaces somewhat codified the low rumblings there had always been that, someday, potential chaos would have to be tempered by agreed tagsets of industry- or discipline-wide scope. But XML is becoming a mass-market phenomenon because the fixed tagset(s) of HTML hit a wall, and the frustrated refugees are flocking to the most appealing possible promise: define your own markup. John Cowan is undoubtedly sincere when he declares > We do not want a fixed element type "Date" analogous to "H2" or "over". > Nevertheless, if the 'problem' is to be solved with markup alone, fixed element types are precisely what will eventually result. We speak of markup--the XML Recommendation describes markup and prescribes the most basic handling of it--but the builders of XML processors are the true audience for this philosophizing and these rules of markup. Parsers, of course, provide only the first stage of processing. The discussion of names, dates, etc. illustrates precisely the sort of processing which will have to be done and which we, as the xml-dev's, will presumably have to build. In the first place, I do not believe that we can simply withdraw, or even substantially limit, the perceived freedom to create tags and then to apply instance markup following personal inclination. In my evangelical experience, this is the one salient characteristic which draws every newcomer to XML. On the other hand, there are only a limited, and more-or-less easily enumerated, number of processes which can be performed on dates, or names, or other such classes of data. These processes are not only suitable for standardization, but ripe for it. Where this leaves us is with the need for an intermediate layer, not only to map between idiosyncratic markup and standardized process, but specifically to strip out the 'presentational'--including the inherently cultural--leaving only the 'ontological', which may be easily processed. This intermediate layer may well be a species of architectural forms, but it is predicated on a need for processing, not just for declarative markup. Notice, too, that our 'styling' mechanism must perform a mirror-image operation on the output of these standard processes. Dates submitted in one 'cultural' form, mixing presentational elements with their ontology, must be stripped in order that we may perform date arithmetic, but their subsequent presentation requires the reintroduction of cultural conventions--perhaps from a different culture than those which were originally stripped away. Some sense of how many layers of such cultural information must be stripped, and then re-introduced by degrees, is apparent in John Cowan's example of the sort order of Icelandic names. The details of that example imply that at least some standard name-handling processes must manipulate data sufficiently stripped that it requires the re-introduction of cultural data in order to establish a (presentational) sort order, even if that sort is only to facilitate the further handling of the data by another standard process. Walter Perry 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
|