Minutes for XML Core WG telcon of 2011 October 5

Attendees
---------
 Norm
 Paul 
 Liam

[3 organizations (4 with proxies) present out of 9]

Regrets
-------
Glenn
Henry
Daniel
John
Jirka

Absent organizations
--------------------
IBM (with regrets)
Innovimax
Univ of Ediburgh (with regrets)
Daniel Veillard (with regrets, proxy to the chair)
Jirka Kosek (with regrets)
John Cowan (with regrets)

Our next telcon after this week is in two weeks on October 19.

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


> 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).
> 

Accepted.

> 
> 2. Miscellaneous administrivia and document reviews.
> 
> Schedule of telcons
> -------------------
> Our next telcon after this week is in two weeks on October 19.
> 
> 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 is now open:
> 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
> 
> 
> 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).

ACTION to Henry continued.

> 
> 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 concluded it was not feasible to implement Jirka's proposals
> using xproc alone.
> 
> ACTION to Norm:  Try to implement Jirka's proposals using XSLT+XProc.
> 

Norm fulfilled this action; 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, Liam, do you have any opinions here?  Is there any
reason not to add a pointer to the registry somewhere in
the SOTD section?

> 
> 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.

> 
> He also suggests that someone should 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/2011Sep/0007
>

Received on Wednesday, 5 October 2011 16:12:46 UTC