OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xml-dev] Implementations not specifications are the problem was Re: [xml-dev] IDs considered harmful

> > "(iii) It doesn't work with streaming output. This is in my
> view the most
> > important technical problem"
> >
> Err, so wouldn't it be easier to fix the streaming output
> systems...
If you want in XSLT to be able to say "add this attribute to the result
tree, and by the way, it's an ID", then you aren't going to be able to
produce the output serially, as you can at present, because the fact that
it's an ID has to go at the start of the document. ID-ness also has to be a
property shared by all attributes of the same name (qualified by element
name of course).

This relates to the other point I made:

>>>Maybe that should be fixed in XSLT, not in XML?
>> It would be easier to fix it in XSLT if it was first fixed in the
>Is-it a new kind of game? Or maybe a private joke?

No, this wasn't a game or a joke. In the InfoSet, ID-ness is a property of
the attribute information item, it's not a property of the attribute
declaration, in fact the attribute declaration isn't even in the InfoSet.
XSLT transforms a tree to a tree, and the idea is that the tree reflects the
InfoSet as closely as we can make it. But if the result tree doesn't contain
attribute declarations, but does contain ID-ness as a property of the
attribute instance, then we're going to end up with a tree that can't be
serialized to XML, whether in streaming mode or otherwise.

You can't parse an XML document to an InfoSet, make arbitrary changes to
properties of objects in the InfoSet, and then serialize back to XML. I
don't think that's a joke at all.

Mike Kay