XML Core WG Status and Open Actions as of 2012 June 19

The XML Core WG telcons are every other week.

Our next telcon will be 2012 June 27.


Status and open actions
=======================

XML Core WG Charter
-------------------
The amended XML Core WG charter that allows us to work on
XInclude 1.1 is currently out for AC review.  Please get
your AC rep to complete the review.  The call for review is at
https://lists.w3.org/Archives/Member/w3c-ac-members/2012AprJun/0059


Fall TPAC
---------
There will be a TPAC meeting in Lyon, France in October/November:
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Mar/0006

We have signed up to have a WG f2f there.

Likely to attend:  Norm, Liam, Henry, Jirka, Mohamed
Not likely to attend:  Glenn, Paul, John, Daniel


xml-stylesheet and HTML5
------------------------
Hnery took an action to file a bug about xml-stylesheet
handling.  Done:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14689

Henry has done a lot more testing and filing of results to date.
Henry's tests are at
http://www.w3.org/XML/2011/11/ssTests/
You need to look at the README and README2 files there.

The CSS2 spec says something about styling XML with CSS.
Henry also notes http://www.w3.org/Style/styling-XML.en.html.

ACTION to Henry: File a bug against the HTML5 spec saying that
it should support styling XML with CSS.


issues with the Polyglot draft:  BOM
------------------------------------
Henry sent email with various potential issues at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Nov/0037

We discussed the point about the spec recommending [P1] the use of
the UTF-8 BOM.

[P1] http://dev.w3.org/html5/html-xhtml-author-guide/#character-encoding

Henry thinks we converged on this in email on Wednesday 11 January:
See
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Jan/0007

Henry filed an issue against Polyglot about the BOM:
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012May/0000

Someone pushed back saying that the BOM is more robust than
the meta as a way of signaling UTF-8, so we shouldn't make
meta the preferred way of doing it.  The proposed compromise
is that neither would be listed as preferred.

We're okay with that compromise.

ACTION to Henry:  Accept the compromise.


issues with the Polyglot draft:  xml:space and xml:base
-------------------------------------------------------
See the minutes at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Jan/0016
for the discussion.

Henry has drafted two issues regarding xml:space and xml:base in
the Polyglot draft and HTML5 for WG review; see
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012May/0001
and provide comments.

Norm thinks Henry's draft is fine.  Let's submit it and
see what happens.

ACTION to Henry:  Submit his comments on xml:space and xml:base.


XInclude 1.1
------------
On 2012 February 14, we published
XInclude 1.1 Requirement and Use Cases
http://www.w3.org/TR/xinclude-11-requirements/

An updated charter is being reviewed by the AC. We don't expect
any pushback, but in practice it will probably take a couple months
before we really have a new charter.

Meanwhile Norm is willing to continue to be editor of XInclude 1.1,
and we have started discussions at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Jun/thread#msg6

So far, we have provisional consensus as follows:

* To add a fragid attribute.

* Some wanted to deprecate xpointer, others didn't, though in either
   case it's less a technical issue than "political".

* If both xpointer and fragid are specified, they should be identical.
   If not, some wanted to make this some kind of error, but not fatal
   and not something that triggered fallback.  Others didn't feel it
   needed to be an error, but again, that's less a technical issue than
   "political".

   If both xpointer and fragid are specified, when parse=xml, the value
   of xpointer should be used; if parse is not xml, the value of fragid
   should be used.

*  We decided to change @parse to allow other values (besides xml and text).
    The effects of other values are implementation dependent, and 
unrecogized
    values are a "recoverable error" which causes fallback.

*  In XInclude 1.0, we define "resource errors" which cause fallback.  Now
    that we have something other than a resource error that we want to cause
    fallback, we are going to change the terminology throughout the spec for
    errors that cause fallback (resource error -> recoverable error).

Regarding what attributes get copied and how, we appear to lean
toward copying only namespace qualified attributes.  If we do this,
we still need to decide what to do about multiple rooted inclusions
and what to do when both the xinclude and the root included element
have the same attribute specified.  Regarding multiple rootedness,
our options include:

1.  give up on any attribute copying unless the inclusion
      is single-rooted.

2.  do all attribute copying to all top-level elements in
      the inclusion and let the application deal with multiple
      identical xml:id's.

3.  do all attribute copying to all top-level elements in the
      inclusion except if there is more than one top-level element:
    a.  don't copy xml:id to any of them
    b.  only copy xml:id to the first in document order.

Regarding attribute conflicts, Jirka and Liam seemed to think
the xinclude value should win, and John--after a pause--appeared
to agree.

ACTION to others, esp. Norm, Henry, Daniel:  Think about the
xinclude 1.1 issues discussed above and comment.