[SML] Whether to support Attribute or not?

[Philip Nye]

"Clark C. Evans" wrote:
> 
>   SML cannot drop attributes unless it provides
>   a resonable alternative.
...
> I clearly see the different role that content plays
> as opposed to attributes. The border and cellpadding
> attributes *modify* the state of the table; where
> the tr element content is *part-of* the table.
> The border attribute recurisvely applies to
> every one of the table's children by virtue
> of how the table is drawn.  In a similar way, the
> colspan changes the last td element so that its
> funciton is completely different -- a child of td
> does not have this power.

You are basing all your arguments on the _convention_ you like to use
for what goes in attributes and what in elements (meta-info in
attributes, info in elements). There is no requirement in the syntax for
this usage.

If you say that with SML you will feel obliged to devise a similar
convention for making semantic distinctions that is fine, but as it is
items are often made attributes or elements for silly processing reasons
and not for semantic ones at all.

i.e. If you want to be able to specify a set of alternative tokens, or a
default value, use an attribute. If you want a structured value use an
element. This is nothing to do with semantics.

Furthermore, why should meta-info be forced to be unstructured? - the
answer is that it isn't. When you need structured meta-info you just
break your attribute/element convention and probably no-one notices. It
certainly does not break anything in XML.

Dropping attributes entirely removes the artificial distinctions and
places the responsibility on the schema - but only in applications where
there is a distinction to be made.

An alternative is to make
<foo bar="xyz">...
equivalent to and freely interchangeable with
<foo><bar>xyz</bar>...

This gives the advantages of readability and allows you to apply similar
conventions if you want to.

> >From a pratical sequential processing perspective,
> this syntax distinction is very necessary --
> otherwise one would have to wait until the entire
> content of an element to be read "just-in-case"
> one of the children modified its parent.  This
> would be a nightmare, and would require random
> access... hence more memory, and thus, completely
> undermine SML's application to less powerful devices.

This is just not true - it all depends on the schema you are using
(whether defined in a formal schema language or otherwise). In terms of
simple text scanning the only requirement is that the modifying
"meta-info" element appears before the data or "info" element. This can
be made a requirement in the schema and it would seem an obvious thing
to do in some cases. I could equally say that allowing elements means I
have to assign a far bigger memory space to process my opening tags
since they could have several kilobytes of name-value attribute pairs
embedded in them.

Philip Nye

-- 
Philip Nye
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye at freenet.co.uk


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)