LISTSERV mailing list manager LISTSERV 15.5

Help for XML-L Archives

XML-L Archives

XML-L Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave XML-L
Reply | Post New Message
Search Archives

Subject: Re: Visual metaphors for attributes
From: Robin Cover <[log in to unmask]>
Reply-To:General discussion of Extensible Markup Language <[log in to unmask]>
Date:Fri, 12 Jun 1998 08:41:25 -0500

text/plain (62 lines)

John E. Simpson wrote:

> "What would be some good visual metaphors for editing attributes?"
> Answering this would require figuring out how to characterize the
> relationship between elements and attributes. I'm not looking for a formal
> definition of the relationship necessarily; by the time someone starts
> hankering for a WYSIWYG interface, she's no longer got formal definitions
> at the top of the priority list (if she ever did). No, the question really
> is, when someone's holding a rough sort of element tree in his head and
> about to embark on "editing" it, what are attributes' roles in the tree?
> Leaf coloration? Is this getting too cute?

At this juncture, one could justifiably ask whether the notion of an
"attribute" as modeled in XML/SGML syntax is suitably close to the
average user's notion of an "attribute," or whether the XML/SGML
notion is just fundamentally broken.  No question that it's very
difficult to design a user interface which supports editing hierarchical
"depth" and the semantic richness of text, as multidimensionally
conceived.  No question that it puts a burden upon a user to grok
a certain artificial notion of serialization when the information in
the user's problem space is not intrinsically serialized, and especially,
in that [complex] attributes of complex objects *have* no inherant
serial order.  If you add to that burden a certain lack of semantic
transparency (aka lack of correspondence between the user's
conceptual model of the real world objects and the model offered
by the editing interface, because complex attributes have to be
modeled *as elements* [no real choice here]). . . well, the problem
becomes even more difficult.  If you expose the markup syntax to the
user at this point, it presents a conflict because it will not,
for any complex application, match the real world situation with
respect to objects and their (real) attributes.

In the judgment of many, the "attribute" problem becomes somewhat nasty
at just this point.  Not that any design of a structure editor is
easy in any case.

In my work environment, the best thinkers have concluded that the
solution is task-driven tools that provide sensible interfaces to
objects on a per-class basis.  That is: engineer as many common
UI constructs as possible, but expect that the editing tools for
individual objects will look pretty different, but will be intuitive
because they respect the user's view of the object at the conceptual
level.  How these objects are used in the construction of a
(generic) "document" is a different matter.  "Authors should create
information; programs should generate documents."

In this world, where the focus is upon the semantics of the
information, a markup representation in SGML/XML is just one
possible view of the information.  Objects can be told how
to display themselves (recursively) in terms of markup models.

All told: it's about semantics, not syntax.

Just my 2 cents.
Robin Cover                    Email: [log in to unmask]
6634 Sarah Drive
Dallas, TX  75236  USA          >>> The SGML/XML Web Page <<<
Tel: +1 (972) 296-1783 (h)
Tel: +1 (972) 708-7346 (w)
FAX: +1 (972) 708-7380

Back to: Top of Message | Previous Page | Main XML-L Page



CataList Email List Search Powered by the LISTSERV Email List Manager