W3C home > Mailing lists > Public > www-xml-infoset-comments@w3.org > January to March 2001

RE: XML Infoset Comment Resolution: issue-query-*

From: Michael Rys <mrys@microsoft.com>
Date: Mon, 26 Mar 2001 10:02:39 -0800
Message-ID: <EC67B042372C27429014D4FB06AC9FAF0262709E@red-msg-29.redmond.corp.microsoft.com>
To: "Richard Tobin" <richard@cogsci.ed.ac.uk>, <www-xml-infoset-comments@w3.org>
Cc: <pgrosso@arbortext.com>, <lehors@us.ibm.com>, "Paul Cotton" <pcotton@microsoft.com>, "Jonathan Marsh" <jmarsh@microsoft.com>, "W3C XML Query WG (E-mail) (E-mail)" <w3c-xml-query-wg@w3.org>
Hi Richard, thanks for the comments. For my answers, see below.

Best regards
Michael

> -----Original Message-----
> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]
> Sent: Monday, March 26, 2001 8:20 AM
> To: www-xml-infoset-comments@w3.org; Michael Rys
> Cc: pgrosso@arbortext.com; lehors@us.ibm.com; Paul Cotton; Jonathan
> Marsh
> Subject: RE: XML Infoset Comment Resolution: issue-query-*
> 
> 
> > Comment: I do not see the problem when performing cut-and-paste of
> > elements. Every element has it's own namespace associated to itself.
> 
> Right, but the in-scope namespaces are needed for resolving prefixes
> within content or attributes.  If you copy the element y from
> 
>   <x xmlns:foo="http:/foo"><y>foo:bar</y></x>
> 
> then it should continue to have the foo prefix in scope
> so that if the content (foo:bar) is interpreted as a QName, it is
> interpreted correctly.

I find this to be outside of the scope of the Infoset proper. That
foo:bar is interpreted as a QName is either guaranteed by XML Schema
(and then the namespace association is part of the PSVI), or it is
application specific. As such, this does not belong into the Infoset.
Applications will have to make sure that the move occurs according to
the intended semantics.

> > On the contrary, I believe
> > that having all in-scope namespaces associated with an element
> > information item will make XInclude or an update language much
harder
> > to implement, since now all in-scope namespaces have to be
recomputed
> > for the infoset.
> 
> The intention is the in-scope namespaces never have to be recomputed.
> They are just copied with the element.  Namespace *attributes* may
> have to be recomputed to make them consistent with the in-scope
> namespaces if the infoset is re-serialized, but only if it is
> re-serialized.
> 

This is not clear based on the Infoset description and would be a
requirement against both XSLT and XQuery. I find this to be a bad
requirement, since it potentially leads to large overhead and data
bloat. Let the applications deal with preserving the information for
embedded QNames by using XML Schema.

> <a:A xmlns:a="uri1" xmlns:b="uri2">
>    <b:B>
>       <c:C xmlns:c="uri3"/>
>    </b:B>
> </a:A>
> 
> <a:D xmlns:a="uri4">
>   <e:E xmlns:e="uri5"/>
> </a:D>
> 
> > With the current infoset, the inscope namespaces of b:B and c:C
> > in the old document are (uri1, uri2) and (uri1, uri2, uri3)
> > respectively. For a:D and e:E they are
> > (uri4) and (uri4, uri5) respectively.
> 
> Right.
> 
> > After the move they are:
> 
> > b:B: (uri4, uri2)
> > c:C: (uri4, uri2, uri3)
> > a:D: (uri4)
> > e:E: (uri4, uri2, uri3, uri5)
> 
> According to the current infoset, they are the same as they 
> were before.
> 
> Why do you want them to be different after the move?  Surely they
> should be the same!  It is unfortunately impossible to serialize the
> document so that this remains completely true - there is no way to
> unbind prefixes - but surely it is essential that, for example, b:B
> continues to have prefix a in scope in case it contains a QName using
> that prefix.

Again, If you have data that has semantics beyond XML1.0 plus
namespaces, it belongs into a Post-X infoset. XML Schema gives you a
QName datatype, which exactly gives you the semantics that you wish
without bloating the Infoset.

In any case, this current draft does not make any of this clear.

Best regards
Michael
Received on Monday, 26 March 2001 13:49:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:00 UTC