Minutes for XML Core WG telcon of 2011 October 19

Attendees
---------
Glenn xx:15
Norm
Paul 
Henry
Liam
Jirka

[6 organizations (7 with proxies) present out of 9]

Regrets
-------
Daniel


Absent organizations
--------------------
Innovimax
Daniel Veillard (with regrets, proxy to the chair)
John Cowan 

The telcon that would usually occur on November 2 is cancelled
due to TPAC that week, so our next 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
> -------------------
> The telcon that would usually occur on November 2 is cancelled
> due to TPAC that week, so our next 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:
> 
> Expected:  Paul, Norm, Henry, Liam, Mohamed
> Regrets:  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>

Henry starts to agreed with John's comment at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/0015
and realizes that his earlier suggestion doesn't work, so he suggests
we drop this now.

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

ACTION to Henry continued, perhaps for our f2f.

---

Namespace well-formed external parsed entities
----------------------------------------------
At
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/0018
Norm brought from Query/XSLT the question of what 
namespace well-formedness means for an external
parsed entity.

We will continue in email and pick up at the f2f.

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

ACTION to Paul: Ask Ian what we might be able to do, hoping
we can make a change to the SOTD with an in-place edit.

Henry volunteers to edit a second edition.

Norm wonders if this will open the door to other things.

> 
> 
> 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 Wednesday, 19 October 2011 16:02:21 UTC