Subject: Re: Potential new issue: PSVI considered harmful - msg#00118

List: org.w3c.tag

Date: Prev Next Index Thread: Prev Next Index

I see several different problems with the PSVI.

(a) It makes documents less self-contained.

(b) Applications that depend on a PSVI now require a very complex, heavy-weight schema validation process, rather than a relatively simple parsing process.

(c) Applications that depends on a PSVI must agree not only on the choice of schema language but also on the choice of mechanism to locate the schema. As has been pointed out, xsi:schemaLocation is just hint; there is no single way that is mandated for an application to locate a schema. XML Schema does not specify a single way to get from a URI specifying a document to a PSVI; it only specifies the way to get to a PSVI from a URI specifying a document together with a mapping from namespace URIs to schema locations.

(d) The PSVI is not XML; this is the most insidious problem. With something like default values, you can perform a normalization process and produce a self-contained document where defaults are explicit. The declaration of default values defines a mapping from an XML infoset to another instance of an XML infoset. It is not necessary to add complexity to applications to deal with default values. However, the W3C XML Schema PSVI is not like this; a PSVI is not an XML infoset. You cannot perform the PSVI infoset augmentation as a separate XML to XML transformation. All applications dealing with the PSVI are dealing with a different, more complex structure than applications that deal with pure XML. Applications communicating with the PSVI become much more tightly coupled: when applications communicate using the XML infoset, they do not have to share an address space, because there is a standard serialization of an XML infoset as XML, but this does not apply with the PSVI. I believe this is a catastrophic architectural mistake in XML Schema, and it needn't have been like this: schema infoset augmentation could and should be defined as an XML to XML transformation process.

James

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Bad practice: Overriding HTTP content-type with a URI reference

In the last call working draft of SGRS, http://www.w3.org/TR/speech-grammar/#S2.2.2 a reference to another document can specify the content type of the destination object in a way that overrides any content-type provided by the HTTP server . The same was true of (svg? smil?). I understand that the intent was specifically to be able to reference a lot of existing data in legacy (probably unregistered) mime types. This is obviously counter to the architecture, but meets a real need in practice for servers which just can't be configured by the people who publish on them. This is fact a social/tools mess - if the config files took local directory input then all would be well. Maybe a compromise is to only allow the link to specify the content-type when the server is FTP (or something else with no content-type control) or the HTTP server returns text/plain or octet-steam, which seem to be used for "don't know" types. It is of course consistent to indicate "the contents of this document expressed in whatever language but then reinterpreted as application/whatever" but in practice such references are kludges and would for example make the introduction of new versions of application/whatever more difficult. Tim

Next Message by Date: click to view message preview

RE: Potential new issue: PSVI considered harmful

-----Original Message----- From: James Clark [mailto:jjc@xxxxxxxxxx] Sent: Sun 6/16/2002 11:29 PM To: www-tag@xxxxxx Cc: Subject: Re: Potential new issue: PSVI considered harmful >(a) It makes documents less self-contained. As are documents with DOCTYPE declarations, stylesheet PIs, and XML include locations. >(b) Applications that depend on a PSVI now require a very complex, >heavy-weight schema validation process, rather than a relatively simple >parsing process. Applications that depend on the PSVI must have a reason for doing so. The above statement is like saying "applications that depend on the Java JVM/.NET CLR must now deal with non-deterministic finalization and the inability to manually manage memory instead of simply running machine code directly" So what? Applications that depend on the PSVI have made the *choice* to do so. >(c) Applications that depends on a PSVI must agree not only on the choice >of schema language but also on the choice of mechanism to locate the >schema. Interesting criticism especially since many consider it a beneficial feature of W3C XML Schema. So what alternative would you propose? >(d) The PSVI is not XML; this is the most insidious problem. > You cannot perform the PSVI infoset augmentation as a separate XML to XML > transformation. > when applications communicate using the XML infoset, they do not have to > share an address space, because > there is a standard serialization of an XML infoset as XML, but this does not > apply with the PSVI. There are XML serializations of the PSVI. Granted, the ones I've seen are rather verbose but they do exist.

Previous Message by Thread: click to view message preview

RE: Potential new issue: PSVI considered harmful

So is it time to quit referring to DTD or schema-spec'd languages as "markup application languages" and begin to refer them as "markup validation languages"? If we are going to separate defaulting out and say this is an application language responsibility, then we just moved it all into the implementation of ??? What goes there? This "Instead of saying that the default value for some attribute is "x", you specify that an application should behave as if "x" had been specified if no value is supplied" moves us into the realm of architectural forms. len From: Norman Walsh [mailto:Norman.Walsh@xxxxxxx] / "Simon St.Laurent" <simonstl@xxxxxxxxxxxx> was heard to say: | I suspect this issue contains at least two architectural sub-issues, | At 11:13 AM 6/12/2002 -0700, Tim Bray wrote: |>So I recommend a TAG finding along the following lines: [...] |> 2. Type-augmented XML has nothing to say about default values |> created in any schema. | | Should Web architecture reply on explicit values provided directly in | messages, or rely on outside mechanisms which provide defaults? | | I'd much prefer the explicit version, but it's hard to argue against | defaults after years of HTML practice. Defaults can be viewed at two levels. At one level, schema validation augments the resulting infoset to include new information items. This is typical attribute or element content defaulting. This kind of defaulting has broader impact than is at first obvious. It introduces interoperability problems if validation is not always required and it makes "identity" transformations difficult or impossible. I'm inclined to think that this sort of defaulting should be avoided. At the very least, I think it would make some sense to separate this from the validation process. The other way to deal with defaults is to move them up to the application level. Instead of saying that the default value for some attribute is "x", you specify that an application should behave as if "x" had been specified if no value is supplied. This has disadvantages too, but over time I've come to believe that they're easier to deal with than the disadvantages of the former. Be seeing you, norm -- Norman.Walsh@xxxxxxx | It is not failure of others to appreciate your XML Standards Engineer | abilities that should trouble you, but rather XML Technology Center | your failure to appreciate theirs.--Confucius Sun Microsystems, Inc. |

Next Message by Thread: click to view message preview

Loading Comments...