XML Core WG Status and Open Actions as of 2012 July 2

The XML Core WG telcons are every other week.

Our next telcon will be 2012 July 11.


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

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.  Regarding multiple
rootedness, we had consensus to do all attribute copying to all top-level
elements in the inclusion and let the application deal with multiple
identical xml:id's.

Regarding attribute conflicts, we had consensus that the xinclude value
should win.

What we're trying to do with XInclude here is just to allow enough
information to be passed through to allow the application to do
whatever fixup it feels it needs to do.

Norm (as editor) will explain in the draft how what we are trying
to do here with XInclude is to leave enough evidence in the post-included
document to allow subsequent processing to be able to do whatever it wants.

Henry says we could define a namespace that says copy me
without any namespace.  But he decided not to propose that
seriously now.

ACTION to Norm (as editor):  Create a first draft XInclude 1.1.