I am not sure I understand your point, how do you expect to be able to apply a style across multiple elements in a HTML document using attributes of existing elements?
Nevertheless you'd have to define selectors or use classes, even XPATH had to come along for XML.
Then you would also have to define property names and value. And you pretty much invented CSS. To apply it by classification, it has to be declared independent from your document tree, then you might as well separate it.
From the example of FOSI in the article, it looks like the SGML elements aren't directly contained within the elements they style but refer them them from attributes (gi="h1", gi="h2", etc.), which is actually more similar in functionality to having external CSS stylesheets than inline CSS (which is what I think you're referring to).
FWIW, SGML also has LINKTYPEs (in addition to DOCTYPEs) for declaring presentation properties using normal attribute declaration syntax. A LINKTYPE can contain a state automaton assigning link attribute values to content elements and for transitioning to other states, but, unlike CSS, doesn't use regular patterns. This system makes sense for print, where a standard task is to assign different horizontal margins on even and odd pages. Using SGML LINK, this can be implemented by declaring two states transitioning to one another over page elements. A regular expression pattern language like CSS, OTOH, can't express the necesssary logic, hence CSS has a large number of extra predicates.
Yes, but only if grouping of subexpressions or non-terminals in grammar productions are allowed (they aren't in CSS).
To elaborate, the problem at hand is to assign different properties to the even and odd elements, resp., of a sequence using just the sequence, alternation, and Kleene star operators in two rules. For example, the rules for the first few items (as) are as follows:
even -> a a | a a a a | ..
odd -> a | a a a | ..
A solution using grouping of subexpressions/non-terminal symbols in grammar rules:
That's a full logic language (like prolog) for selecting things. It's very easy to mess up a prolog program and destroy its performance, so it's not a good thing to have on a web standard.
Maybe something more functional instead of logic would be better.
For comparison, it's also quite easy to mess up the performance of a JavaScript program, and yet it's part of a web standard. My recommendation in cases of poor performance is to improve Prolog systems by features that yield better performance. Examples: better virtual machines, JIT indexing, tabling, constraints, goal reordering as in Mercury etc., all of which are now becoming part of modern Prolog systems.
Important advantages of logic programs over functional ones is that logic programs are typically shorter and more general, and ideally well suited for describing domain-specific knowledge (such as styles and layouts) declaratively. Prolog is already part of the semantic web to considerable extent, albeit disguised as RDF and complex query languages with a different syntax than Prolog. It could have been Prolog all along, and some members of the committees have suggested that in fact.
Fun to hear from another Prolog fan here. Like you, I came back to Prolog from SPARQL/OWL2, and share your opinion. My upcoming SGML system (sgmljs.net) will also feature a full ISO Prolog engine for querying over document metadata (there's even a "tolog" Prolog profile for this, which at one point was considered to become an ISO standard [1]).
Do you know of Prolog systems for layout computation of CSS or other layout languages? I "know" Prince/PrinceXML (Mercury-based) and the begin of a formal specification for CSS as logic/attribute grammar [2] (from 2009).
However, I must correct one misconception: I did not "come back from SPARQL/OWL2" to Prolog. Rather, when the whole RDF/SPARQL hype started, I could only hope that in due time, this will all stop again and turn back to Prolog, which now, years later, is slowly happening. Prolog FTW! It's a great language for formal specifications and declarative descriptions of all kinds of data, including layouts. I hope your project becomes a great success. ISO compliance is definitely a great benefit and will help adoption in large organizations considerably.
I disagree that it's equally easy to mess languages of any other paradigm. One simply does not code a linear time algorithm into a super-exponential time program by mistake in javascript. At least, not often.
That said, the DOM is actually not that large. My comment may be an overreaction.
I was just trying to make the point that in core CSS basic even/odd selection isn't possible, hence the :nth-child()/:nth-of-type() CSS selectors were introduced. SGML LINK doesn't have this particular problem, as it just encodes an automaton using transitions. For example, you can say
<!link even
x #postlink odd [ background-color=gray ]>
<!link odd
x #postlink even [ background-color=white ]>
where "#postlink even ..." means "upon an 'x' element, use gray and transition to the 'odd' link set", from where it transitions back to 'even' state on the next 'x' and so on, so that the current link set is toggled between the even and odd states. You can also set a state for child content with #uselink.
Yes I saw this and though you might be referring to this, but it's still roughly the same, by defining these attribute names and selectors, you are still defining a language, you don't save much to learn. There is not much else to the CSS language.
Nevertheless you'd have to define selectors or use classes, even XPATH had to come along for XML.
Then you would also have to define property names and value. And you pretty much invented CSS. To apply it by classification, it has to be declared independent from your document tree, then you might as well separate it.