Agenda for XML Core WG telcon of 2011 October 19

We have an XML Core WG phone call scheduled for Wednesday, 
October 19, from
          08:30-09:00 Pacific time aka
          11:30-12:00 Eastern time aka
          15:30-16:00 UTC 
          16:30-17:00 in Ireland and the UK 
          17:30-18:00 in middle (most of) Europe 
on the Zakim W3C Bridge, +1 617 761 6200, passcode 9652#.
We also use IRC channel #xmlcore on irc.w3.org:6665 .

See the XML Core group page [1] for pointers to current documents
and other information.  If you have additions to the agenda, please
email them to the WG list before the start of the telcon.

Please also review our group page's task list [2] for accuracy and
completeness and be prepared to amend if necessary and accept it
at the beginning of the call.


Agenda
======
1. Accepting the minutes from the last telcon [3] and
   the current task status [2] (have any questions, comments,
   or corrections ready by the beginning of the call).


2. Miscellaneous administrivia and document reviews.

Schedule of telcons
-------------------
The telcon that would usually occur on November 2 is cancelled
due to TPAC that week, so the following telcon will be November 16.


TPAC week
---------
TPAC will be 31 October through 4 November 2011 in Santa Clara
California. 
http://www.w3.org/2011/11/TPAC/ - Meeting Overview page.

Registration:
http://www.w3.org/2002/09/wbs/35125/TPAC2011/
The XML Core WG will meet Thursday afternoon of the TPAC week.

Likely attendance:

Probably will:  Paul, Norm, Henry, Liam
Maybe:  Mohamed
Most likely won't:  John, Daniel, Jirka, Glenn

********************************************************************

It is worth noting that the UK and most of Europe will be shifting
away from Daylight time on October 30, but North America will be
shifting on November 6.

Since after this week, our next telcon is November 16, we will not
be having a telcon during the "out-of-sync" period, but those
traveling to and from TPAC may need to be aware of the time shifting.

*********************************************************************

standalone declaration issue (from XProc)
-----------------------------------------
The XML Processing Model WG is struggling with how exactly to clarify
the interaction of the standalone declaration between web browsers, 
XHTML, XML, and common practice.

<quote-from-xproc-minutes>
Henry: The browsers aren't going to pay attention to the standalone
declaration.
... Unless we change the XML spec to change the default. The problem is
that the default is standalone=no. So if we ask the browsers to change
to make standalone=no an error, we'll break all XHTML. It's a lose-lose
situation.
... The one thing we could imagine doing is to say that there's a
media-type dependent default which is standalone=yes. What we'd be
asking the browsers to do is two things: (1) give an error in the
presence of an explicit standalone=no, and (2) give an error for
non-HTML XML unless there's an explicit standalone=yes

Norm: In 1997, maybe. But today it's just not worth it. We'd be asking
every user serving non-XHTML XML to change.

Henry: So how would Core feel about saying that the XML XHTML5 spec can
default standalone=no
... If we don't do this, then we should have raised an issue on XHTML5
saying that they're not raising an error when XML says they should.

Further discussion, leading to the observation that standalone is a
validity constraint

Paul: I'm happy to have the Core WG say something if it helps make
things work better.
... as long as it doesn't rewrite the XML spec.

Alex: I think the question is, if you look at the combination of our new
document with the smallest profile and the XHTML5 spec, what's the
interpretation of the standalone attribute.
</quote-from-xproc-minutes>

xml-stylesheet and HTML5
------------------------
Henry started a thread at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Jul/0008

In the HTML5 spec, when dealing with the XML prolog, there is
nothing about processing instructions, so it isn't clear that
browsers would pick up the xml-stylesheet PI.

John Cowan said there was another part of the spec that applies
to that process, but Henry hasn't yet followed up on that.

ACTION to Henry:  Research to ensure that the xml-stylesheet PI
is appropriately referenced from HTML5 and/or 3023bis (the XML
media type definition).

Note that 3023bis could say that browsers should reference
Assoc SS and process the SSPI when processing an XML resource.


Extending Xinclude
------------------
Norm sent email on behalf of DocBook at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Jul/0013
asking whether we want to consider extending Xinclude.

The key issue is that xincluding content can often cause
duplicate ids, and the question is whether we can define
some kind of fix up.

See http://docbook.org/docs/transclusion-requirements/#uc-5
for a use case.

See http://www.docbook.org/docs/transclusion/#d6e180 for
some DocBook proposals for id fixup.

A processor might be able to find ids and/or idrefs if xml:id
is used and/or there is a DTD/schema available, and even if 
that is the case, fixup would only work within the included
module, but is that partial case worth augmenting XInclude.

Liam suggests the only real solution is to do a transformation,
so he doesn't feel there is an XInclude solution.

Norm implemented Jirka's proposals using XSLT+XProc; see
http://norman.walsh.name/2011/10/03/transclusion

There was some follow up discussion as to what we might do; see
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/thread.ht
ml#msg4

Paul said we could say that all attributes on the xinclude element
that are in the xinclude namespace should be copied to the "root"
included node(s).  That one thing would allow a follow up process
such as Norm's XSLT to do the necessary fixup.  If one did xinclude
processing after validation, one could give those extra attributes
defaults in the schema so that they didn't need to be authored.

More discussion, no conclusions except that we should revisit.


XPointer and XPointer Registry
------------------------------
Norm asks whether http://www.w3.org/TR/xptr-framework/
should be updated to point to the XPointer Registry explicitly.

Henry didn't think Ian would allow an in-place edit, though
we could issue a new edition to add the reference.


3.  XML 1.0--see http://www.w3.org/XML/Group/Core#xml-errata

We are creating an XML 1.0 6th Edition and XML 1.1 3rd (or
perhaps 6th) 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.


4.  XML Test Suite.

See also http://www.w3.org/XML/Group/Core#xml-test-suite

ACTION to Henry:  Construct a test case for the XML test suite 
issues raised by Frans Englich:
http://lists.w3.org/Archives/Public/public-xml-testsuite/2007Mar/ 


5.  Namespaces in XML 1.0/1.1--see
   http://www.w3.org/XML/Group/Core#ns1.0
   and http://www.w3.org/XML/Group/Core#ns1.1.


6.  LEIRIs--see http://www.w3.org/XML/Group/Core#leiri

We had planned to issue the following spec editions referencing LEIRIs:

* XML 1.0 6th Edition
* XML 1.1 3rd Edition
* XInclude 3rd Edition

We continue to wait to see what might happen with IRIbis.


7.  xml:id--see http://www.w3.org/XML/Group/Core#xml-id


8.  XML Base 2nd Ed--see http://www.w3.org/XML/Group/Core#xml-base


9.  XLink 1.1--see http://www.w3.org/XML/Group/Core#xlink1.1


10.  XInclude 3rd Ed--see http://www.w3.org/XML/Group/Core#xinclude

We are creating an 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.

Norm sent email at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Sep/0011
saying that the existence of RFC 5147 makes the constraint that
@xpointer must not be present when parse="text" inappropriate.  
He suggests we remove that constraint.

But when parse="text", the resource is not (treated as) XML, 
so what would it mean to address into it via an xpointer?

We could add a "fragid" attribute to xinclude that is only
valid to set when parse="text".  Given the currently defined
fragment id RFCs, that would presumably mean the only valid
value for the fragid attribute would be something complying
with RFC 5147.

Norm also suggested that someone should try to register a text() 
XPointer scheme that implements RFC 5147.

But it couldn't be an xpointer scheme because it doesn't work on
XML.  Yet it seems so useful.  So we need to discuss this more.

Paul and Liam note that one can use the xpath() scheme to address 
first a particular node and then (via, e.g., the xpath substring 
function) particular characters within that node.  Paul thinks 
that is more useful in most cases than the 5147 fragment identifier 
that just treats the entire file as a big text node (though this 
doesn't give you access to "lines" like 5147 does).

Needs more discussion.


11.  Associating Stylesheets.

See also http://www.w3.org/XML/Group/Core#assoc-ss

AssocSS 2nd Ed is now a Recommendation at
http://www.w3.org/TR/2010/REC-xml-stylesheet-20101028/


12.  xml-model

See also http://www.w3.org/XML/Group/Core#assoc-schemas

The Second Edition has been published as a WG Note at
http://www.w3.org/TR/2011/NOTE-xml-model-20110811/


paul

[1] http://www.w3.org/XML/Group/Core
[2] http://www.w3.org/XML/Group/Core#tasks
[3] http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/0008

Received on Monday, 17 October 2011 13:18:17 UTC