Re: Updated XInclude draft

Paul Grosso <paul@paulgrosso.name> writes:
> I realize that I never really understood this wording.

It's definitely a little confusing.

> The sentence most in question for me is:
>
>   While this does not prevent subresources from being
>   identified by URI (See Architecture of the World Wide Web
>   [Identification]), it does preclude the use of those
>   identifiers directly within XInclude.
>
> I remember the Makoto issue (that we can't put a fragid on
> the URI directly), and I suspect that's what this sentence
> is about,

That's the conclusion I reached.

> but when I read that sentence, I find unclear
> what the referents for "this" and "it" are, and I'm not
> sure what "use of those identifiers directly within XInclude"
> really means.  In fact, I'm not sure why this sentence is
> here at all--it seems unnecessary.

I agree. I almost deleted it, then thought I'd try to do as little
violence to that paragraph as possible. However,

> Maybe the whole Note should read something like:
>
>   A key feature of XInclude is that it allows a resource to
>   be cast to a user-specifed type for inclusion. The returned
>   media type is therefore essentially ignored for the purposes
>   of inclusion processing, and the syntax of the fragment
>   identifier of the returned media type will generally not
>   be applicable to the user-specified type.
>   Therefore, in XInclude, subresources of the included resource
>   are identified by a separate xpointer or fragid attribute
>   which is applied after the casting takes place.

I think that's an improvement. Anyone disagree?

> But other than that all the rest looks good to me.

Thanks.

                                        Be seeing you,
                                          norm

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