Subject:Catalogs and Caching Author:(Deleted User) Date:12 Mar 2004 07:38 AM
I have finally got catalogs working as you suggested - using xsi statements, However if I use remote instances for resolution within the catalog we appear to be getting some form of caching, where schema changes are not picked up by the parser. Can you please explain this behavour and confirm if there is a cache used?
Subject:Re: Catalogs and Caching Author:(Deleted User) Date:12 Mar 2004 08:03 AM
Hi Martin,
At 08.05 12/03/2004 -0500, you wrote:
>From: "Martin Roberts"
>
>I have finally got catalogs working as you suggested - using xsi
>statements, However if I use remote instances for resolution within the
>catalog we appear to be getting some form of caching, where schema changes
>are not picked up by the parser. Can you please explain this behavour and
>confirm if there is a cache used?
The API Stylus uses to read from the network use the same cache of Internet
Explorer; so, you can manually clear it from the Tools|Internet Options
page (clicking on the button "Delete Files", or clicking on "View files"
and deleting just the one you want to refresh). If you have access to the
web server configuration, you may want to check if it is properly reporting
the modification time of the file.
Subject:Re: Catalogs and Caching Author:Billy Boy Date:30 Jun 2004 03:57 AM
This caching situation is becoming unworkable. If I am working on a XML and XSD and I keep changing the XSD then I don't wnat to keep clearing the cache via the internet option.
It there another way so that the current XSD is always referred to rather than the cached version?
Subject:RE: Catalogs and Caching Author:Ivan Pedruzzi Date:30 Jun 2004 12:02 PM
Billy,
Are you using OASIS catalogs?
Ivan
> -----Original Message-----
> From: stylus-studio-tech Listmanager
[mailto:stylus-studio-tech.listmanager@stylusstudio.com]
> Sent: Wednesday, June 30, 2004 4:00 AM
> Subject: Re: Catalogs and Caching
>
> From: "Billy Oliver" <billyoliver@paypoint.co.uk>
>
> This caching situation is becoming unworkable. If I am working on a
XML and XSD and I keep changing
> the XSD then I don't wnat to keep clearing the cache via the internet
option.
>
> It there another way so that the current XSD is always referred to
rather than the cached version?
>
> Regards
>
> Billy
>
>
> --
> To reply: mailto:stylus-studio-tech.7629@stylusstudio.com
> To start a new topic: mailto:stylus-studio-tech@stylusstudio.com
> To login: http://www.stylusstudio.com/SSDN/
> To (un)subscribe:
mailto:stylus-studio-tech.list-request@stylusstudio.com
>
Subject:Re: Catalogs and Caching Author:(Deleted User) Date:30 Jun 2004 05:38 PM
At 03.59 30/06/2004 -0400, stylus-studio-tech Listmanager wrote:
>From: "Billy Oliver" <billyoliver@paypoint.co.uk>
>
>This caching situation is becoming unworkable. If I am working on a XML
>and XSD and I keep changing the XSD then I don't wnat to keep clearing the
>cache via the internet option.
>
>It there another way so that the current XSD is always referred to rather
>than the cached version?
Hi Billy,
just to confirm, are you saving the XSD to a web server, with the XML
referencing it using http://.../schema.xsd?
Which web server are you using?
Subject:Re: Catalogs and Caching Author:(Deleted User) Date:01 Jul 2004 08:37 AM
>Thanks for replying.
>
>I am using a 'local' web
>server and I am using a URL
>Address to reference the XSD
>file from within the XML file.
>
>I'm preempting that you will
>say that if I use a UNC
>address then I won't get this
>problem, am I correct?
You are correct: the issue is that when we read from an http source
we make use of the same Windows API that Internet Explorer uses.
This API will first check for the timestamp of the source document
as reported by the Web Server, and check it against the version
found in the local cache. On a couple of occasions we have found that
updating a document on the web server will not invalidate the version
in the cache.
This is why I have asked you for the product you use as web server
(IIS, Apache, or other) to see if we can fix the problem at its source.
Infact we would prefer not to take the route of asking Windows to force
the retrieval of the document every time, as this has performance
implications.