[
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.
http://www.w3.org/TR/xpath20/#id-type-conversion
"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
useless.
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
yth11.html
Debug XSLT on the fly - http://www-106.ibm.com/developerworks/xml/library/x-deb
ugxs.html
|
