Re: Inheritance/defaulting of attributes
[... original posting from PeterMR remailed...] > >Rick, > That's very clever! It's an attractive, generic way to tackle the problem. > Its downside is exactly what you point out. > >At 16:19 05/10/97 +1000, you wrote: >[...] > >>Perhaps what you need can best be dealt with by defining some >>standard values for the XLL role attribute! (See the values for >>role= below for candidates.) I think the standard definition >>of some role types (i.e. moving "role" into more certain >>architecture") would be highly useful--if no common values are >>defined, role will go the way of PIs and languish in unuseability >>due to meaninglessness. >> >[... clever example snipped ...] > >I agree strongly with these sentiments. XML and XLL are both defined in a very abstract manner. No problem with this in principle, but it must be complemented with: > - tutorials > - examples > - software >and as we both agree > - common methods of tackling frequent problems. > >I agree with you that unless PIs and roles are addressed very soon, they will become useless. Their use is totally unclear to anyone from outside the SGML community and so newcomers won't use them - just as they don't use REL in HTML. > >As a webhacker I don't have the insight into the tools and tricks of the current SGML community :-) but appreciate what can be done with examples like yours and AFs. However unless there is a consistent approach to promoting *how XML can be best used* we are likely to suffer from fragmentation and inconsistency. > >I have consistently asked for the developers to show *how* X*L may be used and *what software is required to make it work that way*. Your example shows two levels of indirection using SIMPLE links with default attribute values. The software has to be able to pick up that, although the attributes are [SHOW="EMBED" ACTUATE="USER"], the nodes shouldn't have clickable buttons. This is presumably governed by the values of the roles. IOW with each of your roles, quite a lot of software has to be written. > >The problem with your solution is that it is completely impossible to 'sell' to my community [at present]! (I'm not singling you out - it's true of AFs and all the clever stuff that can be done with remapping, indirection, etc.} I'm probably in a minority, but I'm still clinging to the idea that 'XML is simple'. > >So let me make a plea for those on this list who understand this to suggest some concrete aspects for X*L. Unlike the XML-SIG and ERB (who have to produce a spec and who are clear that this must be as general as possible), we have the opportunity to make concrete suggestions about the best ways that XML might be used. This doesn't stop anyone doing other things differently, but it might stop us ending in a mess. We *have* been able to propose an API for XML (no one is *forced* to use it) and this would seem to have the same importance. > >If nothing is done, here are some scenarios... > - the browser manufacturers produce tools that ipso facto define how X*L is to be used. Different offerings will almost certainly be incompatible, terminology will clash and the power of the language will be lost. > - SGML vendors will produce complex tools and architectures and tell the users that they are easy to learn and use. My experience is that they won't be. > - a few applications (RDF will probably be the first) will capture the world's imagination. People will start hacking without understanding XML, just as with HTML. [BTW I approve of the RDF spec - I assume it's now OK to discuss it? I assume that my current example could also have been done in RDF.] > - lots of people will produce XML applications in limited domains which will be largely incompatible in their philosophy. > >X*L is vastly more powerful than HTML and significantly more difficult. I suggest the following as an analogy. When I learnt FORTRAN there were an infinite number of ways of writing programs, many very bad. With C, there was a bible, but still a fragmentation of style. Slowly, supporting libraries became available which helped to support some of the common ways of doing things. With C++ there was a greater emphasis on common style but (big mistake) no libraries. It was difficult in the early days to write portable applications. With Java, there is a strong consensus of style - not forced, but voluntarily accepted - so it's fairly straightforward to read someone else's code. The delight - for me - is the enormous library of classes that comes with it. I no longer have to implement things like dates, reading files, hacking images, etc. but I can also be sure that what I do interfaces directly with other people. > >We need the equivalent philosophy for X*L. At present it's abstract. It can be implemented in many different ways. The right time to tackle this problem is before there are concrete applications out there - it seems an appropriate role for XML-DEV to suggest best ways of doing things. > > P. > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg 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