- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Wed, 2 Oct 2002 22:53:29 -0400
- To: "Paul Prescod" <paul@prescod.net>
- Cc: <www-tag@w3.org>
Paul Prescod wrote: > > I want my cake and to eat it to and you haven't offered a technical > reason why this is impossible. Sure, the standard answer seems to be: use XSLT to convert your syntax into something standard. > ...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. No doubt. I wonder why Hytime never took off. Was it too complicated? Hard to implement? Should we reconsider decisions made in 1992-1996 in light of stuff available today? Yet even if we reconsider, can Hytime gain the mindset of web folks c. 2002? > > 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. Yep, it allows you to get to the tokens easily without worrying about the details of comma, semis, parens etc. etc. Similarly RDF allows you to get to the semantics (to the extent that this describes a 'graph' or internal model) easily without worrying about the details of elements, attributes etc. etc. > > 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. > Sure ... XSLT ... and its well worth the trouble to write a transform when your syntax is something special. On the other hand when its _close_ to either XLink or RDF, then dealing with a namespaced attribute or a few child elements seems not a huge price to pay assuming that generalized software exists that can do interesting things with either RDF or XLink. That software does exist, and more is being written on a daily basis, for RDF. For XLink, the industry acceptance has been lukewarm at best -- and while I personally like XLink, I just don't see lots of XLink aware applications. Jonathan
Received on Wednesday, 2 October 2002 23:11:43 UTC