W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > September 2010

3023bis and XPointer [was: Draft TAG telcon minutes of 2010-08-19 available]

From: Grosso, Paul <pgrosso@ptc.com>
Date: Wed, 1 Sep 2010 10:59:40 -0400
Message-ID: <9B2DE9094C827E44988F5ADAA6A2C5DABF0F08@HQ-MAIL9.ptcnet.ptc.com>
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

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