Re: XInclude 1.1 draft [was: XML Core WG Status and Open Actions as of 2012 September 10]

Paul Grosso <paul@paulgrosso.name> writes:

> Under 3.1, the parse attribute, we say:
>
>  Values other than "xml" and "text" are implementation-defined.
>
>  Implementations must treat unrecognized values of the parse
>  attribute as a recoverable error....
>
> I'm concerned that "unrecognized" is confusing.  I know we
> want it to mean "not recognized by a given implementation",
> but someone could take it to mean "not officially recognized
> by this spec" aka, something other than "xml" and "text".
>
> Maybe (reworded as desired):
>
>  An implementation must treat any value of the parse
>  attribute that is doesn't recognize as a recoverable error....

Ok.

> -----
>
> Under 3.2, we have two "musts" without saying what kind of
> error it is if you don't.

Ah. That's the recovery action. I've reworded slightly.

> If the xpointer attribute is present when parse="text",
> is that a fatal error, a resource error, or a recoverable
> error, and if the lattest, what is the recovery?

Fatal error.

>
> If none of xpointer, fragid, nor href attributes are specified,
> is that a fatal error, a resource error, or a recoverable
> error, and if the lattest, what is the recovery?

Fatal error.

I've added text to that effect.

> There are two sections numbered 3.2.

Stupid DTD validation.

> The erratum was not applied completely.  That paragraph did
> get moved, but the first "are" still needs to be changed to
> an "is".

Sloppy, sloppy.

> In section 4.3, we now talk about "the resulting XIncluded
> document".  However, throughout (the rest of) section 4,
> we talk about the "result infoset", and I think we should
> do likewise here.

Good catch.

> The first paragraph in section 4.3 hints at why one might want
> to do attribute copying, but no where do we really explain this.
>
> We should add some wording to motivate/explain how attribute
> copying could be used by an application to solve, e.g., the
> ID problem.  We also need to say explicitly somewhere that
> this XInclude spec says nothing about what an application might
> do with the result infoset to address, e.g., the ID problem.
>
> In our June 27 telcon minutes, we said:
>
>  Norm (as editor) will explain in the draft how what we are
>  trying to do here with XInclude is to leave enough evidence
>  in the post-included document to allow subsequent processing
>  to be able to do whatever it wants.
>
> We need to get that sentiment in to the document somewhere.
> Perhaps as a new 1.6 section.

Ok. I'll take a stab at that, but not right this second.

I've updated the draft with the other fixes.

                                        Be seeing you,
                                          norm

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