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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ Lists Home | Date Index | Thread Index ]

Hi Tim,

>> As a W3C XML Schema user, I'm frustrated by the inability to
>> actually get at all the "interesting" information that validation
>> against a schema adds to a document, and want XPath 2.0 to give me
>> that mechanism.
> The problem with that wordview is that Xpath/Xquery are clearly
> mostly going to be used at application run-time. I think the
> proportion of cases where XMLSchema validation happens at
> application run-time is going to be way short of 100%. I personally
> think's actually going to be way short of 25%, it's useful for
> design support and debugging but it's just not at the right level
> for business-logic validation.
> The basic notion getting wired into XQuery and friends that you've
> basically always run it through a schema is theoretically
> interesting but WRONG.

I think I agree with you in terms of *validation* -- that applications
are rarely going to be interested in validating the documents that
they deal with, except during the initial stages of development so
that they can make sure that all their XML-generating code is doing
its job properly, for example.

I think what I'm after isn't *validation* against a schema, it's
*annotation* by a schema, plus I want it to be a kind of annotation
that doesn't fundamentally alter the Infoset that I operate over
(which is why technologies like XVIF and Regular Fragmentations, or
even pipelines of XSLT transformations, don't meet my need).

Here are some examples of the kind of thing I mean:

1. In my schema, paragraphs, tables, lists and so on are all in a
   "blocks" substitution group. I want to be able to say "all blocks
   should be treated like this". I don't want it to be that when I
   update the schema and add a new block element, I also have to
   update the stylesheet to add it to a list of elements.

2. I want to write a stylesheet that will tidy up some XML by removing
   attributes that have the same value as the default value for that
   attribute, as defined in the schema. I don't want to have to list
   the defaults for all the attributes in my stylesheet; I want it it
   to be that when I update the schema to assign a new default or add
   a new attribute, I don't have to touch the stylesheet.

3. I want to write a stylesheet that takes an instance document and
   creates from it a form that enables the user to change that
   instance document. I want the options that are available to the
   user to be at least partially determined by the options that are
   listed in the schema.

I can find plenty of examples in the stylesheets I've written recently
where being able to use these kinds of annotations, particularly the
first one, would have *really* simplified the stylesheet itself *and*
made it more resilient in the face of changes to the markup language
(writing stylesheets that track a moving target is no fun at all).

So while I agree with you about the *validation* side of schema
validation not being useful aside for design-time support and
debugging, I do think *annotation* side of schema validation could be
very handy (with the right support).



Jeni Tennison


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS