- From: Paul Prescod <paul@prescod.net>
- Date: Wed, 02 Oct 2002 15:34:38 -0700
- To: Jonathan Borden <jonathan@openhealth.org>
- CC: www-tag@w3.org
Jonathan Borden wrote: > Paul Prescod wrote: > > >>In *my* markup language it is my perogative to weigh the costs and >>benefits of elements vs. attributes for myself. My choice should not be >>constrained by XLink or RDF M&S. >> > > > Certainly, and *your* applications will perfectly understand the semantics > of *your* markup language. I want my cake and to eat it to and you haven't offered a technical reason why this is impossible. Dare I mention the H-word. HyTime demonstrated that it is possible to turn any attribute into a locator for any other element and to infer locator roles and link types from element types and attribute names. It used a syntax that was hideous for the language designer but invisible for the language user. The attribute was 100% owned by the language designer in terms of name and even to a certain extent internal syntax. And it was 100% understandable by any Hytime engine (which is to say, either of them). And that was in 1992-1996 without benefit(?) of any of our modern conveniences like namespaces, XPath, the DOM, schemas, etc. > ... I'm not sure that I want to bother figuring all > this out, nothing personal, and particularly for standard languages, I'd > very much like to use standard mechanisms, standard software modules, etc. Who said anything against standard mechanisms and standard software modules? >... > Sort of like how most folks have decided to code in high level languages > rather than machine code. Frequently it is possible to improve performance, > decrease memory footprint etc, by hand optimizing machine code, but at what > cost? I had thought that the general idea of using XML was to allow > application programmers to focus on semantics as encoded in software, rather > than syntactic issues, parsers etc. etc. You are half right. XML allows you to avoid thinking about lexing. But an XML schema is designed to declare a syntax and in fact is just a glorified, er, syntax, for a grammar-definition language. XML caught on because it allowed people to define their own syntaxes quickly and easily. > ... Generally it is possible to take > _any_ XML language and further optimize it (perhaps in terms of > characters/document etc.) by rewriting it in SGML e.g. using tag > minimization etc. or s-expressions, or whatever other custom syntax... but I > thought we were trying to get -beyond- such arguments (e.g. parens vs. angle > brakets) The cost/benefit ratio in giving up control of parens vs. angle backets is huge (because there is NO algorithm for parsing arbitrary languages in constant time from simple-to-read grammars). But the cost/benefit ratio for XLink and RDF is much smaller. I can easily invent an algorithm to convert from arbitrary XML to RDF or XLink in constant time based on a declarative specification. I had a way of doing more or less that years ago. Paul Prescod
Received on Wednesday, 2 October 2002 18:35:10 UTC