RE: XInclude @xpointer when parse="text"

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Wednesday, 2011 November 16 13:55
> To: public-xml-core-wg@w3.org
> Subject: 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.

If we go with #1, how do you interpret:

xpointer="element(/1/3)text(...)" parse="text"

which would be valid syntax.  Do we just say that any scheme
other than text() fails when parse="text"?

paul

> 
> 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

Received on Wednesday, 16 November 2011 22:11:32 UTC