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] bohemians, gentry

[ Lists Home | Date Index | Thread Index ]

> At 10:42 AM 12/5/2002 -0700, Uche Ogbuji wrote:
> >Two things:
> >
> >1) From my last reading of XPath 2.0, schema "import" was not optional if the
> >document had a PSVI.  If this has changed, this is a big step forward.
> It has always been optional, whether or not the document has been schema 
> validated. (Of course, XQuery operates on the Data Model, not the PSVI).

I don't give a fig about XQuery.  I was talking about XPath.


"XPath is a strongly typed language with a type system based on [XML Schema]. 
The built-in types of XPath include the built-in atomic types of [XML Schema] 
(such as xs:integer and xs:string), and the following special derived types: 
fn:dayTimeDuration and fn:yearMonthDuration (described in [XQuery 1.0 and 
XPath 2.0 Functions and Operators]). Additional type definitions may be 
imported from the language environment via the in-scope schema definitions."

This does not sound optional to me.

And I am happy to substitute "XPath 2.0 Data Model" for "PSVI" if you insist 
on that quiddity.  Just don't expect me to always remember that.

Then there is section 2.3:

"  1. The document can be parsed using an XML parser.
   2. The parsed document can be validated against one or more schemas. This 
process, which is described in [XML Schema], results in an abstract 
information structure called the Post-Schema Validation Infoset (PSVI). If a 
document has no associated schema, it can be validated against a permissive 
default schema that accepts any well-formed document.
   3. The PSVI can be transformed into the Data Model by a process described 
in [XQuery 1.0 and XPath 2.0 Data Model]."

I think I see the outs that you folks claim here.  This sequence is listed as 
an "example" (note that the only other example is described as "synthesized 
directly from a relational database".  Then you refer to XSD rules for schema 
processing.  XSD makes following schemaLocation optional.

I'm not impressed by all this wriggling.  In practice, every XSD processor I 
have used follows schemaLocation.  And by the placement and emphasis of this 
supposed example in a normative section of the spec, you pretty much mandate 
its implementation in this way when an XML document is being parsed.  Even if 
I were a strong typing advocate, I would find this stuff intolerable from the 
POV of interoperability.

You could avoid such misinterpretation, and minimize interop problems by the 
simple expedient of moving the PSVIish nonsense (note the "ish") to a 
different spec.  This is what I've been arguing for.

>  > > Building data types into the schema doesn't seem harmful. That's the
> > > point of a schema, is it not?
> >
> >My point is that it ensures tight coupling.
> I can do queries on data without importing the schemas into a query, and 
> the built-in data types in instances are available whether or not I import 
> schemas into a query.
> It would be very helpful for me if you could explain just exactly what you 
> mean by tight coupling.

In this case, I mean that it is non-trivial in practice to separate the 
low-level XML data from the higher-level schema annotations.

> > > | which means they now affect all XPath, XSLT and XQuery operations on 
> > them.
> > > | This, I think is where the brittleness emerges.
> > >
> > > Sometimes I write stylesheets that are entirely data type agnostic,
> > > but not really very often. I don't see how building data typing into a
> > > particular stylesheet or query is harmful.
> >
> >I didn't say building it into a particular stylesheet or query is harmful.  I
> >said that if the data typing info in the PSVI is used at the basic XPath
> >processing info, that this is harmful, except in skilful hands.
> Can you give me some examples of what you fear?

So now we have gone over specific examples *in this very thread* and not even 
just in past threads.  Yet you continue in this fishing for concrete.  I think 
my suspicion that you're being a tad disingenuous is thus confirmed.

> > > | * The lack of modularity in W3C efforts to incorporate data typing 
> > into XML
> > > | technologies
> > >
> > > Do you mean because they're tied more-or-less exclusively to WXS? Or
> > > do you mean something else?
> >
> >Bound to PSVI, to be specific.  And I also mean that there hasn't been enough
> >work in defining profiles that define generic processing (including
> >constraints processing) for those who don't want static typing.
> Static typing is optional. Schema import is optional. Is this what you are 
> asking for?

No they aren't, except through reasoning that is so legalistic as to be 

Here is what I'm asking for, more specifically: separate static typing and 
other schema-annotation-specific specifications to a separate document which 
is an optional augmentation to XPath 2.0.  Also, provide XPath 2.0 with 
generic extensibility that allows people to plugg in alternative augmentations 
according to their preference.

If you want details and examples, lurk on the XPath NG mailing list, where we 
are working on just such ideas.

Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Tour of 4Suite - http://www.xml.com/pub/a/2002/10/16/py-xml.html
Proper XML Output in Python - http://www.xml.com/pub/a/2002/11/13/py-xml.html
RSS for Python - http://www-106.ibm.com/developerworks/webservices/library/ws-p
Debug XSLT on the fly - http://www-106.ibm.com/developerworks/xml/library/x-deb


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

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