[SML] Whether to support Attribute or not?

Clark C. Evans clark.evans at manhattanproject.com
Mon Nov 29 23:15:52 GMT 1999

On Mon, 29 Nov 1999, Sean McGrath wrote:
> The notion that attributes are a fundamentally different
> type of information is what I find disturbing. I mark up
> a section of law like this:
> <section n = "1">
> <p>
> This Act shall be know as ...
> </p>
> ...
> </section>
> Now is the number 1 "about" the section? Yes. Is it
> part of the content of the section? Yes. Is it somehow
> intrinsically different from the text of the section?
> I don't think so. To those who say attributes are
> always meta-content I say this (with tongue in
> cheek):-
> 	<element aboutelement="false"/>

Ok.  I just find the distinction useful for my
rather strained thought process.  Just for my 
articulation, I'd like to clarify how I see it.

First, something often ignored is context.  Without
a frame of reference there is no way to categorize
anything. So, I agree with your statement above about
no single a universal category for any one item.  However, 
I do find a simple binary split to give insight and act
as a great guide for organizing information:

     The rules, directives, instructions,
     which individually mean nothing in the 
     current context, but taken together give 
     structure to the element.  In particuar,
     these act as "instructions" to the 
     processor which acts on the xml, configuring
     the processor so that it knows how to 
     handle the incoming content.  This information
     is targeted at the target program, not
     the final consumer.


     Those components, which, in the current
     frame of reference, have individual value 
     and are seperable from the whole.  In 
     particualar, these act as "data" to the 
     processor -- the information to be processed.
     This inforamation is targeted to the 
     final consumer.

Anyway, to me the distinction is all too clear and 
it is also irritating when people don't seem to see
it as I do (perhaps this is immaturity).  However, 
I recognize that my description is far from perfect.

However, as the methodology has served me well,
wish to inform others of what I've learned from 
diligent reading and study of others.
> [...]
> >
> >I'm not saying that this is a direct analogy, however,
> >there are domains which attributes are very useful
> >and mixing them with content seems very confusing.  
> I agree they can be confusing to the human eye
> but so too are CALS tables with all the end-tags!

Yep. I'm not so happy with <element <att>val</att> />
but this style of syntax does support a binary
decomposition of the information.   

How well such a thing would work really depends
on valid applications... how well it works in 
the real world.  
> Attributes are a form of markup minimization.
> They are more pleasing to the eye in certain
> situations. Easier to read and all that.

I tend to use them to support this particular
decomposition of the problem domain.  So far
it has proved to give nice rewards in reduced
complexity.  I'm still an XML "adventurer", so
we will see how sustaining the success is.

> >In any case, if SML were to drop attributes, and not
> >provide at least a non-recursive replacement, then
> >I think the solutions using the "simpler" standard
> >would be far more "complicated" than just using XML.
> >
> >And, once again, I'm not sure at all about recursive
> >attributes... I'm just pointing out the possibility
> >and thinking out loud.  Sorry if this makes you unhappy.
> >
> Apologies about the "harrupmph!" of the last posting.
> Got a bit worked up. No offense intended.

Same here.  ;)



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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)

More information about the Xml-dev mailing list