See also: IRC log
Norm: I think we'll take the comments in backwards order.
No regrets heard.
Norm will be unavailable 12 and 19 May
Norm summarizes how he got there.
Henry: I don't have any problem
with that. I think the suggestion is basically good.
... I wish the world was such that the way I like to work would be better supported, but that doesn't seem likely.
... What worries me about the Firefox decision is that it may be the sharp end of a long wedge to drive XML processing out of the browser
Norm: Yes, I think the browser vendors are likely to go that way.
Henry: I replied suggesting that
looking at the standalone setting might be useful.
... But the default for standalone is "no" so that's not really much help.
Some discussion of what the consequences of standalone settings would be.
Henry: What would be ideal would be if an explicit standalone=no was the only way to request retrieval of external declarations.
But that ain't the way it is.
Norm: I think the other part of my proposal that might be worth discussing is that I threw out XInclude
Henry: I thought Henri Sivonen indicated that he had a requirement to support XInclude which surprised me.
Norm: I didn't read the message
that way, but ok...
... I like having three profiles better than four and if we were going to do XInclude I think we'd need a fourth and I didn't want a fourth.
Alex: Is that really
... I think there's a difference between XInclude and external subset fetching.
... External subsets are an artifact of identifying document types and they get fetched over and over again. But XInclude is more like images or links, they're explicit requests by the author.
... You don't want to go do the fetch, don't put the XInclude in.
Norm: Yes, I agree Xinclude is more like images and scripts, but it's more complicated. It's XML. It has fallback, it's recursive, etc. I don't think the browser vendors will do it.
Alex: We could add XInclude and send it out as another Last Call and see what happens.
Henry: I'd like to do a little negotiation in advance.
Norm expresses some reluctance to have another draft with a recommended profile that isn't what the browsers do.
Alex: What about base URI fixup?
Alex: There's a lot of animosity
about xml:id as well.
... but I think we have to put a stake in the ground somewhere.
Paul: Doesn't XHTML have xml:id?
Alex: No, because they already
have an attribute named 'id' that's of type ID
... SVG Tiny 1.2 has the same problem.
... and they had to describe a convoluted workaround for the browser vs. non-browser cases.
Norm: I wonder if we should remove xml:id from the recommended profile as well.
Alex: I'm not sure about that. I
don't think the implementation is a huge issue. Documents which
have both xml:id and id are, I think, pathological.
... If the performance degrades when you do that, don't do that.
Norm: Yeah, I'm not sure either, I'm just wondering.
Alex: I'd like it to stay because it's so useful for fragment identifiers.
Norm: Alex is going to look into
on what we think we've accomplished.
... There's been less resistance than I imagined to my fairly radical proposal. Maybe we should let it sit for a couple of weeks and revisit after we know the XInclude story.
... If we can get some clarity on xml:id in the browser in that period as well, that would be good.
Paul wonders if we could do better about attributes named "xml:id" and "id"