Re: Next steps for the ARIA syntax discussion

Windmills: meet Elliotte (again)

Elliotte...all I'm saying is that just because we have this rather
complex underlying representation of namespaces in XML, doesn't mean
that we have to match that at the level of the syntax.

So if we wanted to define an XML language such that this:

  <foo aria-bah="banana" />

was equivalent to the following (at an infoset level, but shown here
as more syntax):

  <foo xmlns:aria="http://..." aria:bah="banana" />

then we could.

Now, I'm not suggesting that exact syntax...just that in principle we
can consider making things easier for authors, even whilst preserving
the 'old' meaning. This is because, as I said in my second point,
although XHTML benefits from XML itself, it loses a lot because of the
complexity of the XML syntax. (In particular, XML is not great at
combining languages.)

So when I talked about the "underlying representation of a DOM", I was
meaning the DOM representation of a document, after it had been parsed
and loaded into a browser; there is no reason why this representation
can't contain all sorts of 'fixed-up' namespaces to help differentiate
parts of the document that are using different mark-up languages, even
if the original mark-up that was parsed didn't include those
namespaces directly.


I can't see how you arrived at the idea that I wanted to send DOM
serialisations down the wire, though...

Actually, I don't know how you arrived at most of the things you say
in your email, to be honest.

Regards,

Mark


On Wed, Jun 4, 2008 at 2:17 PM, Elliotte Harold <elharo@metalab.unc.edu> wrote:
> Mark Birbeck wrote:
>
>> The first thing I would do is prise apart the syntax and the infoset.
>> I don't see any reason why the underlying representation of a DOM
>> can't be taken as given, even if we fiddle around to remove the need
>> for prefix-explosion in the mark-up.
>>
>
> Cart: let me just attach you to the front of the horse here.
>
> Syntax is the only thing we have. Syntax is the only thing XML brings to the
> table. There is no common data model for XML, and fundamentally there can't
> be one. Syntax is interoperable across domains, operating systems,
> organizations, and countries. Data models don't usually survive the
> transition from one application to the next, much less the transition from
> one computer to another, or one organization to another.
>
> And of all the things XML has brought to the table, about the only one I can
> think of that is worse than namespaces is DOM. It's ugly, inconsistent,
> memory-intensive, slow, thoroughly despised by users, and frankly just
> hideous.
>
> For a spec designed for long-term storage and wire transport, any object
> model is a non-starter. It is flat-out impossible to put objects on the
> wire. Serialized objects are an oxymoron, a self-contradicting fantasy.
>  They are the perpetual motion machine of computing. There's a reason object
> serialization schemes have failed time and again, and it's not just because
> we haven't invented the right one yet. Defining XML in terms of any object
> model would not just be a bad idea. It would be impossible.
>
> (This is not to the say, by the way, that there might not be better syntaxes
> than the one we've labeled XML. There are almost certainly are. But any such
> improved syntax would have to be just that: syntax, not an object model.)
>
> XML did prise apart syntax and the infoset. That's was one of its most
> significant innovations, perhaps its most significant. The infoset is not a
> core feature of XML. It is simply one understanding of an actual XML
> document, not the understanding of a document. The infoset may or may not be
> useful in any given application and developers are free to use it or not as
> they see fit. The genius of XML was precisely in defining an interoperable
> syntax while allowing many different models of that syntax. To define a
> single model while allowing many different syntaxes is precisely the
> opposite of what XML is about, and why XML has succeeded.
>
> --
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> Java I/O 2nd Edition Just Published!
> http://www.cafeaulait.org/books/javaio2/
> http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 5 June 2008 01:40:34 UTC