Inheritance/defaulting of attributes

[Peter Murray-Rust]

[... 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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)