[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/ Uche Ogbuji <uche.ogbuji@fourthought.com> was heard to say:
[...]
| 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.
I'm not quite sure I follow. If the document has a PSVI, it must have
been validated with some schema, so in that sense some schema was
imported at least into the schema validator. But I think that's
independent of whether or not the stylesheet imports any schemas. If
it doesn't, you aren't going to be able to use any types except the
primitive ones, but that's probably ok. (If you needed others, you
could have imported them from a schema.)
| 2) Even if schema import is optional, it is all or nothing. More likely, I
| want to use type information in, say, one template, and not across the board
| for all values.
How do you imagine that would work?
|> 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'm not sure what you mean by building the data types into the
|> instance. If you mean using xsi:type,
|
| Yes. That's what I mean.
|
|> then I agree completely that
|> it's brittle. And wrong. And I'll quickly discard any tool that does
|> it.
|
| I'm curious: Why do you think it is more wrong than building it into the
| schema? Not that I disagree...
Because schema are like colored glasses, I can look at the same
document in eleven different ways with eleven different schemas. The
schema I use describes the context in which I want to consider the
document. Maybe <weight>01234</weight> is an integer in one schema, a
float in another, an blort:baz in a third, and a string in a fourth.
But putting <weight xsi:type="xs:integer">01234</weight> is just
grotesque. That prevents me from viewing the data some other way.
I've always thought the mere existence of xsi:type was a clear
indication that something was broken in XSD. But bright people have
tried to convince me otherwise.
|> | 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.
What "basic XPath processing info" are you imagining that's independent of
a particular stylesheet or query? If I write
<xsl:template match="weight">
I'm going to match on the element with the name weight, independent of
its type. The existence of type information in the data model that I'm
processing (like, perhaps, that the content of weight is an integer)
allows me to write queries based on that type, but it doesn't force me
to.
Now, you might be concerned that <xsl:value-of select="."/> is going
to give "1234" as the value instead of "01234". That's a fair point.
But if you didn't want weight to be an integer, why did you validate
it with a schema that said it was? XPath didn't impose that view.
|> | * 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.
Yeah, I'm concerned about that too. I expect I'll do a fair amount of
processing with non-schema validated documents. Most likely, I'll
validate with Schematron and RELAX NG and then style or query with no
type information.
Be seeing you,
norm
- --
Norman.Walsh@Sun.COM | To create a little flower is the labour of
XML Standards Architect | ages.--Blake
Web Tech. and Standards |
Sun Microsystems, Inc. |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
iD8DBQE977QVOyltUcwYWjsRAoASAJsFUWCt3rVvAmgN3tpW+EqxH1EHhQCfRgsF
7Ih5ADGnh097wd0zKtvn1Fg=
=4s8y
-----END PGP SIGNATURE-----
|
