OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PSVI in the Infoset Spec. (Re: Datatypes vs anarchy)




This mail attempts to address the question of XML Schema intrusiveness and
makes the presupposition that Type intrusiveness is acceptable.  (Obviously
these questions need to be addressed separately.)

Len Bullard wrote:
> So:
>
> o  What is in the base infoset
> o  How can it be extended by application languages
> o  What extensions will be common and how are those spec'd (eg, perhaps
>    decoupling the primitive types from Schemas IS a good idea)

It seems as though one of the primary points of contention is *where* the
infoset contributions have been spec'd (e.g. in xmlschema-1/2).  It seems
that "[element declaration]" for example is benign and open for use by other
schema languages-- I could easily imagine TREX contributing this information
to the infoset proper.  Of course this may be just due to my wrong view of
the Infoset (and belief that there is some one implementation that SAX DOM
and XPath are only shadows of).

Supposing other schema languages could contribute the same infoset items.
Why would XLST2 for example care where it is getting them from?  The current
definition of [element declaration] is located in and in the context of W3C
XML Schemas-- which I think is the issue.  Of course the Infoset spec could
try to take these properties on and the Schema spec could just define
contribution-- but that seems like a bad thing-- I don't mind the Infoset
telling me about the existence of a property but should it really be
*defined* there.  Possible solutions may include

1) Create an extended Infoset with types and change the version # - "Infoset
plus types"
2) Create a new spec that only has types/declarations for content models
defined as an abstract Infoset  - "Types Infoset"
  a) this could defined all of the properties extensively or,
  b) this could refer to examples in the Schemas spec and refer to how the
schema spec
      contributes as a roadmap for other schema languages
3)  Create xmlschema-3 "Infoset extensions" that basically does 2 but is
housed in the schema spec.

If the infoset or types infoset "declares" these properties and the Schema
Spec only defines how it contributes, then the need to rely on W3C XML
Schemas is removed.  TREX could define how _it_ contributes.  RELAX,
Schematron etc. could contribute.  Obviously the "types" model may gain some
properties from other Schema Languages but it seems for the most part doable
with relatively minor wording changes and an extension to the infoset spec.

> This really does look like the VRML debate.  A syntax and an abstract
> object model that can be used with multiple syntaxes.  Madness in that
> last bit so don't go there.

Uh, sorry I tried to go there...

Regards,
Jeff Rafter