Re: Revised Agenda for XML Core WG face-to-face meeting of 2012 October 29/30

On Mon, Oct 29, 2012 at 03:18:53PM +0100, Norman Walsh wrote:
> Norman Walsh <ndw@nwalsh.com> writes:

  thanks Norm for taking the time to send those in a timely manner !

[...]
> Jirka asks to add an agenda item to discuss names that begin with xml,
> such as "xml-data" in one of the Microsoft formats.
[...]
> > 3. XInclude 1.1--see http://www.w3.org/XML/Group/Core#xinclude
> >
> >    Consider the substantive changes hinted at by the note in
> >    section 4.5, namely using MIME content-types for the value
> >    of the parse attribute and associating the fragment
> >    identifier syntax with the MIME content type.
> 
> Norm reviews a summary of Daniel's comments[4].
> 
> General nods of agreement.
> 
> Some discussion of how we deal with MIME content type values.
> 
> We need to say that XInclude will attempt to treat the resource as the specified
> content type. The purpose of finer granularity in parse types is to allow additional
> fragment identifier syntaxes to be used.
> 
> Appeal to media type hierarchy: you may know the media type or you may know the
> suffix or you may know the family.
> 
> That's the fallback story for media types; we already have a fallback story for
> fragment identifier syntaxes that aren't understood.
> 
> Media types for which you can't understand fallback are treated as recoverable
> errors.
> 
> ACTION: Norm to revise the draft to use media types for the parse attribute.

  Of course all of this sounds good from my perspective, thanks all !

> >    Consider the backwards/forwards compatibility story.
> 
> We think the use of media types finesses this issue. It certainly
> seems a better compromise than a new namespace or a version attribute.
> 
> > 4. xml-stylesheet and HTML5
> 
> Some discussion of the existence of test cases for the stylesheet PI and
> what those tests would mean. Absence of a concrete spec which answers questions
> such as https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c8 is possibly
> a stumbling block.
> 
> Liam: I guess my question is, what's the minimum change needed for us to
> be happy with this version? For me, I'd be ok with a non-normative statement
> that the xml-stylesheet PI may also be used to point to XSLT stylesheets.
> 
> Henry: We need to find out where the xml-stylesheet PI is even mentioned
> in the spec.
> 
> Liam: What we need to avoid is a normative reference to CSS without a
> reference to XSLT. I think we need to make sure that the editor understands
> that we need to say something at a higher level. There's a lot of work that
> could be done to improve interoperability, and that's where test case would
> be involved, but that doesn't need to be in the first recommendation.

  +1 fairness between the various styling options is what we should aim
at
[...]
> >    Can we coordinate a discussion with HTML5 folks this week?
> 
> Liam has talked to Mike Smith. Norm will talk to the editor.
> 
> The HTML WG isn't going to accept normative spec changes, so we should
> just work on a non-normative note.
> 
> Henry: I think we should work on some use cases and see if we can help
> get some normative text moving forward for at least some future draft.
> 
> Liam: I think we've probably outlined what we think is the best
> long-term solution is, in broad strokes [see above, --scribe]. We're
> not likely to get the WG as a whole to agree to another normative
> section at the moment. If that's the case, I think we should try to
> figure out what the section should look like. By the time we've
> figured it out, HTML will be even closer to being frozen. In the
> meantime, I think we should try to craft a non-normative sentence that
> broadly describes what current behavior is.
> 
> Liam: Section 10 is a non-normative section about rendering with CSS,
> so I think we should be able to have a similar statement about XSLT
> at the same level of conformance.
> 
> Norm: I think the green "Note" sections are non-normative. In 5.6.3,
> how about we propose:
> 
>   Note: Many existing user agents support the 'text/xsl' (or
>   'application/xslt+xml') style sheet type, with XSLT [ref] as the
>   relevant supported styling language. When the browsing context has a
>   StyleSheet of that style sheet type, such agents transform the
>   current XML document using the XSLT stylesheet retrieved from the
>   style sheet location (typically supplied via an xml-stylesheet
>   processing instruction) and rendering (or otherwise processing) the
>   document that results from that transformation. The precise details
>   of this process will be defined in a future specification.
> 
> General agreement that this is ok.

  ACK

> ACTION: Norm to pass this note along to the HTML5 WG.
> 
> Henry: I'd like you to include the fact that we'll continue to help
> provide additional test cases to aid in the development of the future
> specification.

> > 5. Error recovery note
> >
> >    Consider Liam's suggestion to document error recovery.
> >    See http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Sep/0002

  /me need to read and comment appropriately, but lack time ATM,

   thanks again,

Daniel


-- 
Daniel Veillard      | Open Source and Standards, Red Hat
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/

Received on Tuesday, 30 October 2012 08:17:37 UTC