RE: 3023bis and XPointer

[Dropping the TAG from the recipient list, as I think this
is mostly just my confusion.]

> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]
> Sent: Monday, 2010 September 06 6:17
> To: Grosso, Paul
> Cc: public-xml-core-wg@w3.org; www-tag@w3.org
> Subject: Re: 3023bis and XPointer
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Grosso, Paul writes:
> 
> > [Henry] said to the TAG on 2010-09-02:
> >>     <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?
> 
> XPointer Framework, as it says. 

[Well, if it has said "conformance ... *to* the XPointer framework"
I would have understood, but I wasn't sure how to parse "conformance
requirement *for*...."  But, whatever.]

> 3023bis requires support for the
> element() scheme as well, as you point out.

True, XPointer Framework doesn't require the support of any
particular scheme--just the shorthand pointer aka barenames.

But what I was trying to point out is that minimum conformance 
to XPointer Framework also requires parsing the multiple scheme 
syntax even if none of the schemes are recognized.

Perhaps this was all well understood in the TAG discussion.

> 
> >>     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.
> 
> I don't think I was scribed particularly accurately, in the second
> quote above.  What I was trying to get at was that if your
> spec. defines a semantics for barename fragids, that's sufficient wrt
> 3023bis, because the only things you can point at with the element()
> scheme XPointers are element infoitems, which are the same things you
> can point at with barenames, so the same semantics will of necessity
> work for either.

I could still not understand your previous paragraph, but
your example below has you application supporting element()
but the zany spec only requiring shorthand pointers.  So I'm
guessing what you're trying to say above is that, if a media
type spec (e.g., zany) defines its fragment identifier to be
just shorthand pointers (barenames), then any application
that conforms to 3023bis will be sufficient to handle that
media type.  Is that correct?

But an application that does not support the element() scheme
when processing a URI reference in an XML document does not
conform to 3023bis, correct?

> 
> That is, imagine the following scenario:
> 
>  1) I pass a URI of the form
>     http://example.com/foo/baz/mumble.xyz#element(/1/2)
>     to an application;

Now I'm confused again.  Above I assumed you were saying that
the zany media type defined its fragment id as just shorthand
pointers.

Nope, I'm not understanding you yet.

paul


>  2) The application GETs /foo/baz/mumble.xyz from example.com;
>  3) The Content-type of the response is application/zany+xml;
>  4) My application conforms to all the necessary specs, as follows:
>      a) 3023bis and the XPointer element() scheme;
>         So it can extract the 2nd daugher element of the document
>         element of the XML document corresponding to the response
>         body;
>      b) The semantics mandated by the specification governing the zany
>         language for individual XML elements, because the zany spec
>         described the semantics of barename frag-ids, which identify
>         elements;
>  5) I win -- my app has everything it needs to proceed.

Received on Monday, 6 September 2010 14:37:47 UTC