Re: SD2 - Structured Attributes [fmt]

In message <3.0.32.19970519085259.006919fc@pop.intergate.bc.ca> Tim Bray writes:
[...]
> 
> Conclusion: Human document desginers should decide what's an element
> and what's an attribute.  And computer software that needs to pull
> a named chunk of data out of a document should be prepared to use
> either.

I have no strong feelings about whether information is transmitted as 
attributes or content (and BXML (before XML)) I used a content model for URLs
- I have now switched to HREF.

The key point - easily overlooked - is that by using two highly structured
information components (attributes and content) you almost certainly put
additional work on the implementer.  Unless they behave *identically*
you have to design them very well so that a single piece of software can
manage both.

In XML-LANG we have a very simple model.  A parser can simply read the 
name/value list and output it to ESIS/TREE with almost no exceptions.  It
*may* have to do special things with attribute TYPES (ID, NOTATION, etc.).
There is only one hardcoded entity (XML-SPACE) and look how much discussion
that has generated.  

I am very worried at this stage about implied semantics.  It's clear from 
the XML-LINK discussion that people make assumptions about how applications
will behave, and those assumptions are not identical.  One concept 
which has been introduced is inheritance - I don't have a problem with that
but need to know whether it's a general model.  The methods for attribute
inheritance and content inheritance would be so apparently different that
we cannot regard them as equivalent in practice.  (People don't mind the 
attributes of a daughter being inherited from the mother (e.g ACTUATE)
but they'd howl if new content suddenly occurred from nowhere).

When I looked at the data attribute proposal I was concerned about *how*
and then *where* it would be implemented.  I'm very worried about implied
semantics being left to the 'application'.  That is a sure recipe for them
being implemented differently (for all sorts of worthy reasons).  We can't
and shouldn't avoid them, but we have to work very hard to make it clear
exactly where they are to be processed and how.  That's why I keep shouting
for a post-parser - a generic semantic processor would be another description.

It is going to be a tough struggle to get consistency of implementation.  
There are two approaches:
	- make it so hard there is only one person who can do it.
or
	- make it simple enough that most people arrive at the same behaviour.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

Received on Monday, 19 May 1997 17:53:18 UTC