- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Wed, 1 Sep 2010 10:59:40 -0400
- To: <public-xml-core-wg@w3.org>
I'm using these TAG minutes to discuss some things within our WG for now. > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf > Of Yves Lafon > Sent: Wednesday, 2010 September 01 8:49 > To: www-tag@w3.org > Subject: Draft TAG telcon minutes of 2010-08-19 available > > Online at > > http://www.w3.org/2001/tag/2010/08/19-minutes.html > rdfURIMeaning-39-27 Generic Fragment ID Processing > > yves: xhtml+xml is compatible with generic processing > > yves: svg+xml has no conflict with xpointer generic processing, it > defines a function with a syntax compatible with xpointer > > noah: is xhtml forbidding xpointer? > > yves: no, xhmtl is just defining id, and how they are used in frags > > <Zakim> ht, you wanted to say that sounds good > > ht: in the xhtml case, in practise, it is fine as bare names is > what you will find > > <noah> I'd like to scribe that more carefully: I (Henry) >think< > (but need to check) that the minimum conformance requirement for > the XPointer framework is barenames Minimum conformance with what? XPointer Framework or 3023bis? The former is at http://www.w3.org/TR/xptr-framework/#conformance and, informally, I believe it requires support for shorthand pointers (aka barenames) plus proper parsing of the possibly multiple PointerPart containing SchemeBased syntax (even if it ignores all given schemes). Of course, this section says: Conforming XPointer processors must report XPointer Framework errors to the application. Applications are free to terminate or recover from XPointer Framework errors in any fashion. which means that, if the xpointer is anything but a shorthand pointer--and the application only understands shorthand pointers--then that is an error and the application is free to do anything. So whatever the application does in that case is conforming. As far as conformance to 3023bis, as you quote below, it also requires support for the element() scheme. > > <noah> From 3023bis: > > <noah> A family of specifications define fragment identifiers for > XML media types. A modular syntax and semantics of fragment > identifiers for the XML media types is as defined by the > [XPointerFramework] (Grosso, P., Maler, E., Marsh, J., and N. > Walsh, > XPointer Framework, March 2003.) W3C Recommendation. It allows > simple names, and more complex constructions based on named > schemes. > The syntax of a fragment identifier part of any URI or IRI with a > retrieved media t > > <noah> Conformant applications MUST interpret such fragment > identifiers as designating that part of the retrieved > representation > specified by [XPointerFramework] (Grosso, P., Maler, E., Marsh, J., > and N. Walsh, XPointer Framework, March 2003.) and whatever other > specifications define any XPointer schemes > > <noah> Conformant applications MUST support the 'element' scheme as > defined in [XPointerElement] (Grosso, P., Maler, E., Marsh, J., and > N. Walsh, XPointer element() Scheme, March 2003.). > > noah: before we interpret the fragment, we need to ensure that the > fragment is conformant to the expected syntax > > ht: SVG allows bare names as well? > > Yves: yes > > ht: as long as you have a xpointer implementation implementing > barenames you are safe It sounds to me like 3023bis is saying the element() scheme must also be supported, so I don't understand the previous statement. > > rfc2023bis is not saying that generic processing must support all > xpointer schemes No, but I think it is saying that the element() scheme must be supported. > > noah: ok to close 450? > > <noah> ACTION-449? > <jar> +1 close action-450 > > <noah> close ACTION-450 > > <trackbot> ACTION-450 Investigate generic processing of svg+xml and > XHTML+xml closed Close with what resolution?
Received on Wednesday, 1 September 2010 15:00:11 UTC