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

XML Core WG Status and Open Actions as of 2011 October 10

From: Grosso, Paul <pgrosso@ptc.com>
Date: Mon, 10 Oct 2011 10:19:00 -0400
Message-ID: <9B2DE9094C827E44988F5ADAA6A2C5DA03C7ED89@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 2011 October 19.

After next week's (October 19) telcon, our following meeting
will be at TPAC, and we will not have a telcon on Nov 2.

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.

Registration is now open:
The XML Core WG is meeting Thursday of the TPAC week.  We will NOT
meet on Friday.

Early registration closes 14 October.

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

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

There was some follow up discussion as to what we might do; see

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.

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
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, 10 October 2011 14:23:53 UTC

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