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

On 2012-09-12 10:33, Norman Walsh wrote:
> Paul Grosso <paul@paulgrosso.name> writes:
>
>> XInclude 1.1
>> ------------
>> On 2012 February 14, we published
>> XInclude 1.1 Requirement and Use Cases
>> http://www.w3.org/TR/xinclude-11-requirements/
>>
>> Norm created a first draft XInclude 1.1 which is at
>> http://www.w3.org/XML/2012/08/xinclude-11/diff.html
> I updated that draft this morning. I think I've completed all the
> outstanding actions except for giving it a "sanity check"
> read-through.
>
> * I decided not to rename "resource error" to "recoverable error".
>    That seemed to make things too complicated. I did add "recoverable error"
>    as a new defined term and it's used in a couple of places.
>

I think I'm happy enough with how "recoverable error" is working
in the latest draft.

Comments:

-----

Under 3.1, the parse attribute, we say:

  Values other than "xml" and "text" are implementation-defined.

  Implementations must 
<http://www.w3.org/XML/2012/08/xinclude-11/diff.html#dt-must> treat 
unrecognized values of the |parse|
  attribute as a recoverable error.... 
<http://www.w3.org/XML/2012/08/xinclude-11/diff.html#dt-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 
<http://www.w3.org/XML/2012/08/xinclude-11/diff.html#dt-must> treat any 
value of the |parse|
  attribute that is doesn't recognize as a recoverable error.... 
<http://www.w3.org/XML/2012/08/xinclude-11/diff.html#dt-recoverable-error>

-----

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

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?

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?

-----

There are two sections numbered 3.2.

-----

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

-----

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.

----

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.

-----

paul