RE: xml:* attributes

While I like the reduction of XML to the absolute minimum necessary, I think this goes too far.  

The ability to use XML in this way seems to exist today - correct me if I'm wrong.  

I think we will have in MicroXML a variation on XML that has (once again) no/poor support for the Web - which IMHO is where the whole proposal breaks down.

Yes, you will have to add some facility to allow format spec authors to define and declare elements and attributes.  But the key attributes which drive the web will be left open for re-invention, as they are in XML.

There would be pressure to put semantics in the xml: namespace which don't belong there, if it was left as the only place with semantics in uxml.

Notwithstanding, where will recognizable, simple hypermedia affordances be defined, not to mention lang and base URI?

Peter
________________________________________
From: James Clark [jjc@jclark.com]
Sent: August 17, 2012 2:14 AM
To: micro xml
Subject: Re: xml:* attributes

After giving this a lot of thought, my preference is for A (no colons
in attribute names anywhere).

The following considerations have influenced me.

a) I want to minimize the things in MicroXML that make sense only if
you know the historical context of MicroXML. If somebody who knows
nothing about XML reads the MicroXML spec, I want their reaction to
be: this is a pretty reasonable way to do document markup.  Wherever
possible I want to eliminate things that would appear strange to
somebody with no XML background. To put it another way, I want
MicroXML not just to be simpler than XML but less ugly (more beautiful
would be going too far).  In my view allowing an "xml:" prefix on
attributes increases the ugliness of the language.

b) Adding "xml:" attributes reduces the self-containedness of
MicroXML.  Even though it's only a SHOULD, adding "xml:" attributes
means users have to consult a broad ranges of existing XML specs to
know how they are supposed to use an aspect of the MicroXML language.

c) Adding "xml:" attributes adds some complexity to the specification:
it's not just a matter of the BNF; there have to be some words too.
It's much less complexity than was in John's editor's draft, but it's
nonetheless a consideration.

d)  It is likely encourage a MicroXML culture where people use xml:*
attributes in their documents and schemas.  I would prefer to
encourage a simpler culture where people use unprefixed attribute
names, as in HTML5.  The presence of colons in some names (even if
only after "xml") is likely to create a negative reaction in some
potential users.

e) I am unconvinced of the utility of the xml:* attributes.  I think
the semantics of some of them are common and important, but I do not
think that much value comes from having particular attribute names
that are bound to these semantics regardless of the document type.

f) If applications really need the document-type-independent binding
provided by the use of the xml: prefix, they are likely to need it not
just for xml:* attributes but for other attributes and elements as
well, which means they will need XML Namespaces. This makes them
unsuitable for MicroXML, since full XML Namespaces are a non-starter
for MicroXML.

None of these considerations is decisive on its own, but together they
make my preference for option A quite strong.

James

On Wed, Aug 15, 2012 at 8:59 AM, 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.
>
> James

Received on Sunday, 19 August 2012 10:15:39 UTC