W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > December 2011

XML Core WG Status and Open Actions as of 2011 December 5

From: Grosso, Paul <pgrosso@ptc.com>
Date: Mon, 5 Dec 2011 12:46:00 -0500
Message-ID: <9B2DE9094C827E44988F5ADAA6A2C5DA042E043D@HQ-MAIL9.ptcnet.ptc.com>
To: <public-xml-core-wg@w3.org>

The XML Core WG telcons are every other week.

Our next telcon will be December 14.  That will be our last 
telcon of 2011.  The following telcon will be 2012 January 11.

Status and open actions

xml-stylesheet and HTML5
Henry and Paul met with Anne van Kesteren at the f2f.

Hnery took an action to file a bug about xml-stylesheet
handling.  Done:

Henry has done a lot more testing and filing of results to date.

One edge issue is having a spec for what browsers should do when an 
XML document has a SS PI pointing to a CSS stylesheet.

Henry's tests indicate most browsers handle this pretty well, but
there is nothing in the HTML5 spec about this.  Do we want something
in there about this?

ACTION to Liam:  Send pointers to examples of support for styling
XML with CSS (either tools or web pages).

HT thinks the status quo is generally correct, we just need to
make sure it is spec-ed properly in the HTML5 spec.

Henry's tests are at
You need to look at the README and README2 files there.

issues with the Polyglot draft
Henry sent email with various potential issues at

We should discuss each point and decide what we think.

Extending XInclude
Henry, Paul, Liam, Murray discussed this at the f2f (see minutes).

Those present generally liked the idea of extending xinclude to copy
attributes on the xinclude element down to the root included element,
but we didn't agree on details.

Some issues include:

1.  exactly what attributes to copy?  Henry and Liam preferred to 
copy un-prefixed attributes (except those in the xinclude spec) too.

Norm worries what this would mean if we add another attribute
in the XInclude spec?

Henry wants to be able to have unprefixed attributes copied
onto the root included element.

Henry: we could add a new "copy me without prefix" namespace 
to xinclude.

Norm doesn't need that, but could live with it.

2.  what to do about attribute conflict (error or one or the other

3.  whether we should "log" additions (e.g., via an attribute that 
says what attributes were added).

At first, we didn't think this was much of a concern, but then we
realized perhaps it was something worth considering.

4.  whether we should have some way for targets to say whether they
can be xincluded and/or, when included, have attributes added.

We had a discussion about xinclude being like img/@src rather than
a/@href in that xincluding things is basically "stealing" them.

Yes, it's worth thinking about this a bit, but it seems like
this issue exists already elsewhere, and it may not make sense
to worry about this in XInclude.

We aren't quite ready to start drafting Xinclude 1.1,
but discussion will continue.

Liam tells us that it's okay to work on requirements for an
XInclude 1.1, but before publishing a FPWD, we'll need a charter
revision.  He doesn't anticipate any problems, provided there's 
a realistic schedule for getting to Rec.

LEIRIs and new editions
We continue to wait to see what might happen with IRIbis.

XML 1.0 6th Edition and XML 1.1 3rd Edition
ACTION to John:  Update the XML sources for XML 1.0 and 1.1
to reflect any errata and the LEIRI reference.

On hold awaiting resolution of IRIbis.

XInclude 3rd Edition
ACTION to Paul:  Update the XML sources for Xinclude to reflect 
any errata and the LEIRI reference.

On hold awaiting resolution of IRIbis.

XInclude @xpointer when parse="text"

Henry, Paul, Liam, Murray discussed this at the f2f (see minutes).

Previous email discussion at

We seem to have three choices:

1.  allow use of the @xpointer attribute when parse=text
2.  add a new "@textptr" attribute to use when parse=text
3.  add a new "@fragid" attribute to use in all cases and possibly
    deprecate the @xpointer attribute

The assembled group was generally positive about working on a solution
of some sort.  It felt like the "right" solution if we could time-travel
backwards would be #3, the easiest spec change was to #2, though some 
of us felt that #1 was the best choice at the present.

Paul restarted the email discussion at
Received on Monday, 5 December 2011 17:46:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:43 UTC