RE: lang implementation report

Thanks for the clear statement of your position, which we can provide to
the Director in making the final determination whether the expedient
path we've chosen by putting [language] in XInclude is the right way to
deliver this functionality.  The WG again today confirmed their
viewpoint that it is.

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Monday, July 12, 2004 3:59 PM
> To: Jonathan Marsh
> Cc: www-xml-xinclude-comments@w3.org
> Subject: RE: lang implementation report
> 
> At 3:22 PM -0700 7/12/04, Jonathan Marsh wrote:
> 
> >We recognize that this is a cost-benefit tradeoff with room for
> >legitimate viewpoints on each side.  We are willing to escalate your
> >dissent through our Proposed Recommendation process if you'd like.
> >Please let us know whether you are satisfied that we've considered
your
> >point of view adequately, or whether you'd like the Director to
consider
> >this point of contention during his review.
> >
> 
> The practical side I'm OK with. It's a pain in the ass, but it's
> doable which I know because I've done it.
> 
> I am still concerned with the broader theoretical implications of
> this scheme though. In particular,
> 
> 1. Using the XInclude spec to create a new generic Infoset property
> strikes me as very questionable. This should be done with a revision
> to the Infoset spec, not through the back door like this. The
> inclusions property is a little less objectionable because 1) It's
> clearly in scope for the XInclude spec. 2) It's unlikely to be of any
> interest to anyone beyond XInclude. 3) It has no impact on the
> serialized result document.
> 
> 2. The new Infoset property is redundant with the values of the
> attribute properties for xml:lang attributes. This is a bad thing. It
> means they can get out of sync.
> 
> 3. The idea that was expressed recently by Glenn Marcy that attribute
> inheritance somehow went beyond xml:lang, or that it could in certain
> circumstances, I think is actively harmful and not supported by the
> spec.
> <http://lists.w3.org/Archives/Public/www-xml-xinclude-
> comments/2004Jul/0003.html>
> I' don't know if this was just a personal opinion or the opinion of
> the working group. If it's just a personal comment, no big deal; but
> if this is the opinion of the working group then I think there's a
> much bigger issue hiding underneath the discussion of this one
> attribute that should be brought to the surface and discussed
> explicitly.
> 
> What I suggest is that the XInclude spec be rewritten so that the
> current behavior remains but is defined purely in terms of the
> appropriate attribute information items. I see no need to introduce a
> new property for the element information item to have the desired
> effect. It would be much simpler and more consistent with existing
> specs and APIs to define this purely in terms of attributes.
> 
> --
> 
>    Elliotte Rusty Harold
>    elharo@metalab.unc.edu
>    Effective XML (Addison-Wesley, 2003)
>    http://www.cafeconleche.org/books/effectivexml
> 
>
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaula
it
> A

Received on Wednesday, 14 July 2004 14:31:06 UTC