Lists Home |
Date Index |
- From: Sebastien Sahuc <firstname.lastname@example.org>
- To: "Clark C. Evans" <email@example.com>, Sean McGrath <firstname.lastname@example.org>
- Date: Tue, 30 Nov 1999 12:00:46 +0100
> From: Clark C. Evans [mailto:email@example.com]
> 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.
I Completely agree with this guideline since I expect attribute to add
behaviours to elements. Indeed when you need some action to be
performed on behalf the element like making an element stateful
(ID="...") for further reference (IDREF="..."), or to differenciate
two elements with a -kind of CSS- 'class' atribute instead of
encapsulating these elements into other elements.
On contrary elements act as content.
> 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
Not only irritating but also hazardous, since I agree I don't use that
much attributes, but when I do, it really makes sense to use them, and
removing support to attribute frightens me more than anything.
> 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,
> Archived as:
> http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:firstname.lastname@example.org the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:email@example.com the
> following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)