|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: bohemians, gentry
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








