Shouldn't XML be expressive enough to model E-R constructs directly?

I am not sure if the following makes sense. For the gist, skip to the Conjecture paras. (Please don't be distracted by details when I say something that is not quite right in the numbered sections: they are examples not assertions.)

1. Typed nodes, untyped endpoints, untyped edges.

SGML's ESIS (Element Structure InformationSet, akin to SAX) was a list reported events ("information") from parsing a document. So we can view it as nodes where each node has two unlabelled edges, except the first and last which have one only.

There are 3 types of node: data (characters), tag, declaration.
There are five types of tag: start-document, end-document, internal entity reference, external entity reference, start-tag, end-tag, processing-instruction.

These may have various properties: e.g., for a start-tag, generic identifier and attributes

There are six types of declaration: doctype, entity, element, attlist, notation).

These may have various properties: name, value, etc. e.g. For an internal entity, a name, and text.

The tag types are partially ordered: declarations must come before all element tags, attributes "tags" must come immediately after an element-start tag.

2. Typed nodes, typed endpoints, untyped edges

The XPath 1 Data Model has six types of nodes: document, element, text, attribute, comment, processing-instruction, notation.

Element, attribute and processing-instructions are labeled: the element name, attribute name, and processing-instruction target.

There is one document node with an edge to one element node. An attribute node is a name-value pair with a property to indicate if the node is an ID.

There are edges are unlabelled, untyped but their endpoints have labels called the "axis": child/parent, preceding/following, attribute/parent, namespace/parent.

An element node has only one parent end-point, one preceding endpoint and one following endpoint. All edges have an element at one or both ends.
Child/parent edges have an ordering property. (This might be considered a label.)

The network is a tree, routed at the document node.

3. Untyped nodes, typed edges, untyped endpoints

This a kind of view that a text editor might have (ignoring markup declarations) allowing top-down navigation into various files. It is a tree of anonymous nodes and named set of resources/files/objects called entities.

An entity is a text entity or non-text entity.
Nodes are anonymous and untyped

Each node is itself a sequence of text ranges in text entities and an ordering property
Each node therefore represents a text run in contents of an element, with entity references dereferenced but not merged, rather than the element itself.

There are five types of edges: data, element, attribute, comment, processing instruction, ID/REF

Element, attribute, processing instruction and ID/IDREF edges have names.
Edges are directed from, to.
Edges may also have text ranges (e.g. for the tags, if their location is useful to the application)
Apart from the root node, all nodes have one element edge connected by the "to" endpoint.
Except for elements, each node connects to only one edge.
Element, data, attribute, comment and processing-instruction edges form an ordered, directed tree.
ID/IDREF edges are named by the IDREF value. Consequently, the "from" endpoint with a node with an particular attribute edge connecting to a node with a value containing that identifer (i.e. an IDREF or IDREFs attribute), as does the "to" endpoint (ie., an ID attribute)

The document is therefore a directed, possibly cyclic rooted graph, where the nodes are themselves trees of possibly overlapping ranges of text in entities.

4. Attribute-labelled nodes with attribute-labelled edges.

An example is Chen's Entity-Relationship Model: it has three types of nodes: entity, relationship and attribute.

Nodes are labelled: the entity name, relationship name, attribute name.
Edges have no type or label, but their end-points have a cardinality property: for end-points of edges involving attributes, this may not be greater than 1.
All nodes have at least one edge. A node cannot have an edge to the same type of node, and an attribute node only has one edge (i.e., there are "entity attributes" and "relationship attributes".)
One attribute connected to an entity can be the "primary key".
The network is a graph. Edges and nodes do not have any ordering property.

Conjecture: XML cannot represent #4

XML's strength is that it can be viewed as node-labelled or edge-labelled networks in all sorts of ways.

However, while we can have attributes that attach to nodes or that attach to edges, there is no way in XML itself to attach attributes to both nodes and edges. Which is what the E-R model wants. You have to go outside XML to some higher layer that may give a view of the document with some attributes coming in on nodes (or edges) associated with edges (or nodes.) This impacts every part of the XML ecosystem, which also needs to somehow convey this out-of-band non-schema information, where it exists.

For example, in a start-tag `< buttons type="wooden" xml:lang="de">...` the @type is an attribute of buttons, but the @xml:lang is an attribute of the element's contents which are in German. In E-R terms, one should be an entity attribute and the other a relationship attribute. (Please don't quibble about this example, please focus on what I am trying to communicate, not on the details of what @xml:lang applies to in its specification, etc: I know what some of you are like :-) )

So what people often do, to get "pure" modeling, is like `< buttons type="wooden">< data xml:lang="de">...` to get an attachment. But this does not in fact let you know which attributes belong to edges and which to nodes, it just creates another edge and node. You need to go outside.

How could this be resolved? My preference would be a specialized = delimiter, like =@, in an upgrade to XML for attributes that apply to the contents (attributes on the node if edges are normally used, and vice versa.)

But in XML 1.n, it could be done by some naming convention, for example, a namespace prefix starting with "data_" on any attribute that should attach to the contents between the tags, not the tag itself. `< buttons type="wooden" xml:lang=@"de">...`

Regards

Rick