[
Lists Home |
Date Index |
Thread Index
]
once one has identified the version, one must still decide whether one can do anything with the content. which depends on whether one can associate the generic
identifiers with processes.
it is possible to delegate part of this decison to a validating parser and then make the ultimate decision based on the namespace name, the schema name, or a
combination of the two, but the ultimate decision is still whether an individual name is processable.
which is why any mechanism which limits the relation between two versions to that between two namespace/schema names will suffer from the disadvantages listed
in the original message.
a more expressive and effective alternative is to associate the processes with static sets of names and to describe versions in terms of relations between the
names in the respective namespace/schema. the description may be realized as an architecture[0], a name mapping[1], or a direct declaration for namespaces[2].
...
[0] http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.1.html
[1] http://lists.xml.org/archives/xml-dev/200209/msg00508.html
[2] http://lists.xml.org/archives/xml-dev/200105/msg00112.html
Ian Graham wrote:
>
> I read the TAG postings (which, amazingly enough, were indirectly
> started by me ;-) -- Joseph Reagle [2] cross-posted some versioning
> questions I'd previously posted on RSS-DEV [1] ).
>
> So, yeah. It's clearly a messy problem.
>
> But it would be nice to have some discussion on this list (or somewhere!)
> of practical experience, to know which ways are good - or outrageously
> bad.
>
> I can't imagine the company I'm working for is the only one confronting
> this problem, and looking for a decent (if admittedly interm) approach.
>
> To summarize what I think I've undersood, we (as in XML developers) can
> currently use the following to identify versions:
>
> 1. namespaceURI
> ...
>
> 2. schemaURIs
> ...
>
> 3. version attribute
> ...
>
> So, I'm still left with the feeling that the best version 'signature' is
> some set of {nsURI, schemaURI} pairs, although I don't know what happens
> if you allow for multiple schema languages in the same context. And I also
> agree that overloading schemaLocation with this information -- and using
> ad-hoc tricks to encode version 'numbers' in the schema URIs -- are
> problems that need to be sorted out.
>
> I also admit that this approach may be entirely bogus ... but I haven't
> heard much feedback from anyone confronting this problem directly.
>
|
