- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Mon, 24 Oct 2011 11:34:27 -0400
- To: <public-xml-core-wg@w3.org>
The XML Core WG telcons are every other week. However, the telcon that would usually occur on November 2 is cancelled due to TPAC that week, so our next telcon will be November 16. Our f2f at TPAC next week will be Thursday afternoon (Nov 3). ******************************************************************** 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. ********************************************************************* Status and open actions ======================= TPAC week --------- TPAC will be 31 October through 4 November 2011 in Santa Clara California. We are planning to have a f2f during this week: http://www.w3.org/2011/11/TPAC/ - Meeting Overview page. The XML Core WG is meeting Thursday of the TPAC week. We will NOT meet on Friday. Expected attendance: Paul, Norm, Henry, Liam, Mohamed A draft agenda is at http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/0038 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. 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. XML potential errata -------------------- We have received several potential errata against XML 1.0 5th Ed at http://lists.w3.org/Archives/Public/xml-editor/2011OctDec/0000 http://lists.w3.org/Archives/Public/xml-editor/2011OctDec/0001 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. 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.
Received on Monday, 24 October 2011 15:35:56 UTC