RE: [xml-dev] Word 2003 schemas available

["Michael Rys" <mrys@microsoft.com>]

You are welcome.

Also note that an application that gets the SQLXML template and has no
clue what the sql:query elements mean, will probably not do anything
with it. And the same is true for an application that does not
understand the XML stylesheet PI.

Conclusion: It is the program that interprets the data that may have
security issue, not the data per se. Although, obviously, for any given
system threat analysis, you will have to look at both and analyze their
interaction...

Best regards
Michael


> -----Original Message-----
> From: Murali Mani [mailto:mani@CS.UCLA.EDU]
> Sent: Tuesday, November 18, 2003 11:21 AM
> To: Michael Rys
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Word 2003 schemas available
> 
> 
> thanks for the clarifications.. This illustrates what the PI in XML
can do
> etc..
> 
> I guess if there is some security/access control aspects in XML, then
> probably a right perspective is: how to give access to different
portions
> of an XML document to different users.. I will keep it in mind, if I
have
> to review works in these areas.
> 
> best, murali.
> 
> On Tue, 18 Nov 2003, Michael Rys wrote:
> 
> > The point regarding PIs is that it is just markup and has no
semantics.
> > Only a processor that sees the PI and understands its target will
act on
> > it. It does not introduce "code" into XML any more or any less than
an
> > element with a specific markup.
> >
> > For example, for SQL Server 2000 we designed a so called SQLXML
> > template: an XML file that contains markup with special names that
> > execute a query against a database. We decided to use a special
> > namespace and XML elements for giving this information, but
> > theoretically, we could have used processing-instructions as well.
XSLT
> > processors for example interpret a special PI as an instruction to
> > transform an XML document containing that PI using the indicated
XSLT
> > transform. Theoretically, XSLT could have chosen an XML element in a
> > special namespace for doing so.
> >
> > There are some trade-offs to be made, but neither approach is more
or
> > less secure per se.
> >
> > Best regards
> > Michael
> 
>