Re: xml:* attributes

On Tue, Aug 14, 2012 at 7:59 PM, James Clark <jjc@jclark.com> wrote:

> On Tue, Aug 14, 2012 at 10:34 PM, John Cowan <cowan@mercury.ccil.org>
> wrote:
> > But the semantics of the xml: attributes is universal,
> > and in order to make the spec self-contained we have to explain what
> > that semantics is.
>
> I think the issue is not so much that xml: attributes are universal
> but whether, in the MicroXML world, they are reserved for use in
> accordance with one or more specs.  If they are reserved, then
> self-containedness requires that all xml: attributes that MicroXML
> allows are described in the MicroXML spec.
>
> The following options all seem to me to be possible
>
> A. xml: attributes are not allowed
> B. xml: is just another prefix.  As far as MicroXML is concerned, xml:
> is not reserved; you can make up your own xml: attributes anyway you
> want and still be MicroXML conformant.  However, if you want to be XML
> 1.0 conformant, you had better use the xml: prefix compatibly with XML
> 1.0.
> C. the xml: attribute is reserved, and must only be used for
> attributes described in the spec
>
> Option C is the least radical and most complex.  Although the
> complexity that this adds to the specification is not huge in absolute
> terms, I think it is very substantial relative to what we have in the
> language at the moment.  Defining specific attributes in the XML spec
> has always had a bit of a smell for me.  As Andrew I think mentioned
> earlier, it seems like a layering violation: a meta-language spec
> should not be in the business of defining vocabularies.
>
> Option B adds a wrinkle to our XML-compatibility story. However, if we
> allowed arbitrary prefixes without requiring them to be declared (as
> in the current Cowan spec), then our compatibility story would already
> be pretty wrinkled.  We should also think about the bare xmlns
> attribute.  At the moment, I believe our story on that is that it's
> just another attribute, which you can use any way you want, but if you
> want to be compatible with existing XML toolchains, you had better use
> it compatibly with XML namespaces. Does self-containedness require
> that MicroXML describe the bare xmlns attribute?
>
> Option A is the simplest option, and is attractive for that reason. If
> I ask myself, "can I do descriptive markup cleanly without using the
> xml: attributes?", then the answer is obviously "yes".  Spelling
> "xml:lang" as "lang" does not impact my ability as an document author
> to do simple yet high-quality descriptive markup. (One could even
> consider having the MicroXML spec recommend a "lang" attribute.) It
> seems to me that the main concrete disadvantage from A is
> incompatibility with existing vocabularies (both XML vocabularies and
> HTML5.)
>
> The right choice is not at all obvious to me: there are strong
> arguments for and against all three options. I think this (together
> with our position on prefixed attributes generally) is the hardest
> decision facing this group.
>

Read this last night and gave myself a chance to sleep over it.

Why don't we start with Option A?  We could possibly reconsider the other
options in later iterations of the spec, whereas it would be trickier to go
the other way.  That said, I'm more at peace with the idea of just banning
all colons in all names than I was yesterday.  At least I find it much less
worrisome than a major break of XMLNS 1.0 compatibility.

OT: There is a long line of arguent that the best solution to the problem
namespaces tackled is some variation on architectural forms.  I wonder if
we'll envision some MicroAF, maybe based on the Cowan or Tennison proposal,
as part of the MicroXML spec.  That way you could e.g. assert which
attributes are used for language assertions at that separate layer.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji