Re: Design question about formats based on XHTML 2

> We already have an excellent mechanism for extending the semantics of
> any XML document in namespaces; there is no need to reinvent this
> function in @role.

Definitely.

I'm finding it more and more difficult to justify role at all because
it seems to be trying to take over from the element name, not do
very limited sub-classing.

As I see it, role is a way of creating sub-classes, of a kind that
extend but do not override the parent class.  It is an awkward mechanism,
because it has been bolted on.  In a real object oriented language, one
would not name the parent in each use, but have a declaration which
identified the subclassing relationship.

As XHTML 2 is not backwards compatible, it would be possible to extend the
XML core to allow one to do proper sub-classing of element names.  To me,
the sub-classing declarations belong in the meta data that forms a DTD
or schema.  There are problems with this, though, in that browsers are
allowed not to read the external subsets of DTDs or any of the schema,
but for the mechanism to work, i.e. to fall back to the superclass,
the browser needs this information.  The best I can think of is to
require the information to be duplicated into the internal subset in
all documents using sub-classing.  Having a normal element for this
information would feel wrong to me.

Sub-classing is a recursive operation, so, if one is stuck with the top
level class as the element name and role providing sub-class information,
the syntax of role needs to provide not just the leaf sub-class, but also
all the intermediate ones.

I think it also needs to be a very narrow definition of sub-classing.
Certainly there should be no multiple inheritance.  As noted above, there
should be no overriding.  And, there should be nothing like the interface
concept.  Taking the recent examples, I consider that the aircraft elevation
constitutes an interface construct and should definitely not use role.
In the legal example, it depends on whether sectioness is a fundamental 
property of the sub-class, and the case was not given in enough detail
to decide.

Generally, if it is at all reasonable to have a containment relationship
(a paragraph containing an aircraft type), the application specific
element type should be contained within the XHTML element, not made a
role of it.  Similarly, if the subclassing only consists of adding additional
attributes, attributes in an appropriate foreign namespace should be used,
without any role or other explicit sub-classing.

PS We seem to be having a lot of problems with mail user agents generating
non-standard Re: prefixes at the moment (e.g. pre-pending Re: when it is
already present, and using Re[<n>]:, which is not the same so will get
Re: pre-pended).  I had to clean up the latter on this one.

Received on Wednesday, 30 August 2006 21:35:09 UTC