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 ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ David Carlisle <davidc@nag.co.uk> was heard to say:
|> Is allowed to, but doesn't have to. 
|
| Quite. Is that really how to specify an interoperable language?

It's less than ideal, but under the circumstances it seems like a
workable compromise. There are folks building implementations where
the burden of keeping the lexical forms would be intolerable. I
suppose one could say to them, "Bzzt. You lose. Design your own query
language for your data, but it ain't XML."

Let's say I've been tempted on more than one occasion and leave it at
that :-)

[...]
| Yes there are ways round it. I could use Xpath 1 for example.
| But why is XPath2 _defined_ to allow this incompatiblity.

Pragmatically: because the use case where you need both
representations in the same processor at the same time doesn't appear
to make the 80/20 cut.

| It appears to be defined that way so that it can call itself an XML
| processing language when really it wants to deal with typed data in a
| database which is thinly disguised as XML with an XML view of the data.

Yeah, I don't understand why they want to do that either. I've seen
presentations that demonstrate that you can take XML Query and
transform it into SQL so you can process the data in the database.
Why, I have to ask, didn't you just write SQL in the first place. But
apparently there are reasons, I'm just not smart enough to understand
them.

| I have no objection to people developing a language for handling such
| data I do object to them so corrupting XPath/XSLT in order to do it.

I'm sympathetic. There was a time when it was argued that there would
be cut-and-paste use cases for XPath across stylesheets and queries.
Given XML Query's odd non-XML syntax and the divergence of XPath
features, I think those arguments are fairly weak today.

I think there are some use cases for typed data in stylesheets (for
processing dates and times, at least). And having type information
available provides some good opportunities for optimization and error
detection.

In any event, I still don't see how providing the ability to access
typed data causes problems except for the case where you want to query
the original lexical form of the data and its typed value in the same
processor at the same time.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | A child becomes an adult when he realizes he
XML Standards Architect | has a right not only to be right but also to
Web Tech. and Standards | be wrong.--Thomas Szasz
Sun Microsystems, Inc.  | 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE973TDOyltUcwYWjsRAnFIAJ40tim4sG9VsK1YWxt5sHV1NAY/XACfY+px
9HtqvUz8x6I6iFYEWPbCYL0=
=+a1C
-----END PGP SIGNATURE-----




 

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

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