Re: XInclude @xpointer when parse="text"

"Grosso, Paul" <pgrosso@ptc.com> writes:
>> -----Original Message-----
>> From: Grosso, Paul [mailto:pgrosso@ptc.com]
>> Sent: Wednesday, 2011 November 16 11:44
>> To: public-xml-core-wg@w3.org
>> Subject: XInclude @xpointer when parse="text"
>
>> At the f2f, we outlined three possible 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
>
> What would be the value of the attribute in any of these cases
> when parse=text?  Would it be just a single fragment identifier
> conforming to RFC 5147?  Or would it follow some sort of
> xpointer syntax that allows for multiple schemes?  And if the
> latter, do we need to have a scheme name for the RFC 5147 syntax?

Interesting question. I implemented it as a text() scheme. I suppose
if we added a @textptr attribute, I'd be inclined to just say it had
to include an RFC 5147 fragment identifier.

> If there is only one way (5147) to address into a text resource,
> then I'm not sure there's a point to allowing multiple schemes,
> but then #1 would appear problematic unless we say that the
> @xpointer attribute has different syntax depending on the value
> of @parse.  That would cause me to prefer #2.

If we say 1, I think we should assert that the "text()" scheme
implements it. Having the syntax be dependent on the parse attribute
is ugly.

Speaking of ugly, if we go with (2), I want the presence of @textptr
to imply parse=text. I think.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com