XML Core WG TPAC f2f meeting minutes

stylesheet assoc in HTML 5
--------------------------

Anne van Kesteren, Henry, Paul

Anne: Currently the HTML5 spec is silent about an xml-stylesheet PI 
that has a type other than text/css.

HT: An xml-stylesheet PI with type=text/xsl in an XML document should
be defined in the HTML5 spec (in section 5.5.3) so that they continue 
to work as they do today.

HT: I have an *xhtml* doc with an xml-stylesheet PI with type=text/xsl.
Does the HTML5 specs cover this case? 

ACTION to Henry: Consider asking the above question of the HTML5 WG
after doing some research to determine what does currently happen.

Anne: An xml-stylesheet PI with type=text/xsl causes the browser to
replace the current dom with a new one.  When it sees one with 
type=text/css, it leaves the dom and redecorates it.

We looked at 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html
#read-xml
(6.5.3 Page load processing model for XML files which is 5.5.3
in the version that HT is using as in the statement below)

XML Core needs to ask the html5 spec editor to add some prose to 5.5.3
so that xml-stylesheet PIs whose type is other than text/css do the
right thing, and in particular for type="text/xsl", to invoke the XSLT 
and replace the dom accordingly as they do today.

ACTION to Henry:  File a bug about the previous paragraph.  Done:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14689

HT: Section 5.5.3 doesn't appear to distinguish between xhtml and 
non-xhtml xml documents.  The spec does not make it obvious what 
should happen for non-xhtml xml documents.

ACTION to Henry:  Think about the above statement and determine
if we need to file a bug report or ask a question about it.


"aambiguous grammar" Errata in XML 1.0
--------------------------------------

[not really discussed at f2f, but we had email consensus.]

We appear to have consensus that:

We never said the productions were non-ambiguous,
and if a parser writer wants or needs to translate them into
equivalent non-ambiguous versions, that's fine, but there is
nothing wrong with the productions in the spec.

[He also had a concern about the [14] CharData production
that Paul also addressed in his response.]

ACTION to Paul:  Reply to the commentor--done:
http://lists.w3.org/Archives/Public/xml-editor/2011OctDec/0003


Namespace well-formed external parsed entities
----------------------------------------------

Henry, Paul, Liam Murray

Previous email discussion at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/thread.ht
ml#msg18

Liam points us to the defn of fn:parse-xml-fragment in
http://lists.w3.org/Archives/Member/w3c-xsl-query/2011Oct/0026

I gather the (current) decision by XQuery is that there is no way
to pass in namespace declarations, and it will only be able to
parse an entity that contains all the necessary namespace declarations.

So rather than figure out how to pass in namespace declarations
so that all fragments could be parsed, XQuery decided to restrict
the usability of fn:parse-xml-fragment to just self-contained
fragments, thereby also avoiding the need to define what it means
for an external parsed entity to be namespace well-formed.

The next time we do a new edition of the Namespace spec, we should
consider defining a version of namespace well-formedness for
external parsed entities (production 78 in the XML spec).


Extending XInclude
------------------

Henry, Paul, Liam, Murray

Previous email discussion at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/thread.ht
ml#msg45

Those present generally liked the idea of extending xinclude to copy
attributes on the xinclude element down to the root included element,
but we didn't agree on details.

Some issues include:

1.  exactly what attributes to copy?  Henry and Liam preferred to copy
un-prefixed attributes (except those in the xinclude spec) too.

2.  what to do about attribute conflict (error or one or the other
wins).

3.  whether we should "log" additions (e.g., via an attribute that says
what attributes were added).

4.  whether we should have some way for targets to say whether they
can be xincluded and/or, when included, have attributes added.

We had a discussion about xinclude being like img/@src rather than
a/@href in that xincluding things is basically "stealing" them.

We will continue this discussion in the WG.


XInclude @xpointer when parse="text"
------------------------------------

Henry, Paul, Liam, Murray

Previous email discussion at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/thread.ht
ml#msg46

We seem to have three choices:

1.  allow use of the @xpointer attribute when parse=text
2.  add a new "@textptr" attribute to use when parse=text
3.  add a new "@fragid" attribute to use in all cases and possibly
    deprecate the @xpointer attribute

The assembled group was generally positive about working on a solution
of some sort.  It felt like the "right" solution if we could time-travel
backwards would be #3, the easiest spec change was to #2, though some 
of us felt that #1 was the best choice at the present.

We will continue this discussion in the WG.

paul

Received on Thursday, 3 November 2011 22:32:44 UTC