Re: Polyglot: the final thread?

Alex Russell wrote:
>
> Just because the polyglot discussion awakens some of the old
> XML/HTML politics doesn't mean it's architectural.
>

Quoting REST:

"Software architecture research investigates methods for determining
how best to partition a system, how components identify and communicate
with each other, how information is communicated, how elements of a
system can evolve independently, and how all of the above can be
described using formal and informal notations."

Do I partition my system by outputting in both XHTML and HTML?  Or can I
communicate information in such a way as to be understood by different
toolchains with different capabilities, allowing elements to evolve
independently?

(Henry S. Thompson) wrote:
>
> Henri Sivonen writes:
>
> > I don't. I think you need to use a text/html serializer at the end
> > of your workflow. As far as publishing goes, the text/html
> > serializer doesn't need to be polyglot. (As seen from your example,
> > a text/html-unaware XML serializer won't do.)
> 
> But that involves me in maintaining two distint-but-equivalent end
> products, the XML one which I use for my own purposes, and the
> text/html one, which I use only for publishing.  That's bad software
> engineering.
> 

That certainly sounds like an architectural issue to me.  There's an
option of two distinct-but-equivalent end products.  However, due to
the nature of the Web architecture, a second option exists with only
one end product.  The second option is less maintenance, and better
allows independent evolvability by not requiring consumers in one class
to be redirected as their capabilities improve (evolvability coupled to
the server).

In an architecture based on declaring media type in a metadata header,
IMO polyglot meets the definition of an architectural issue; therefore,
the TAG's request should stand only as an opinion that it is indeed a
matter of architecture the HTML WG should keep in mind -- this fact
exists regardless of how "strong" a need there is for it, which is hard
to measure and doesn't outweigh Larry's point that W3C should publish a
normative-reference transition path from XHTML to HTML 5 because it's
the responsible thing for W3C to do.

-Eric

Received on Tuesday, 26 March 2013 06:22:15 UTC