[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold wrote:
> At 2:23 PM +0200 10/4/02, Robin Berjon wrote:
>> In the case I am considering however, the document can only be valid
>> because it has been binary encoded using a schema, and it won't encode
>> if it ain't valid.
>
> OK. That may make sense for you, but it seems a very weird and unusual
> use-case.
Not all that weird and unusual as it's already flying well, but imho not
common enough to justify inflicting typed XPath/XSLT upon people that
just need to query and convert documents. They'll just keep using the
features they use today, only they'll be using bloated software to do
it, ie pretty much the situation with Office. That's not desirable.
> If this is accurate, I don't think the cost of complexifying
> the XPath 2.0/XQuery specs with schema awareness vastly outweighs the
> benefit to strange applications that want to binary encode documents
> according to a schema.
That's precisely (one of) the ideas behind this thread: we're looking
for use cases that are solid enough to justify the added complexity. On
this my position hasn't changed: we can appear to find potentially
interesting use cases, but none that are of widespread applicability.
Even with widespread binary XML as described above, users will most
likely rarely need the features of XPath 2.0. Some developers will, and
that's why it can be done in a separate module or layer.
I see no good reason to not have XPath 2.0 Basic and XPath 2.0
TypedWithExtraCheese (as the latter can be argued to be useful at least
within XQuery context, and probably within others). Given that the XPath
2.0 syntax is still in flux, the type-related extensions may even be
specified to be in a different namespace (provided they're function
based, or that axes can be namespaced).
> The implementation experience does not yet
> exists to decided whether this is useful or even possible. It's better
> to let this stuff be experimented with before anybody attempts to
> standardize it.
Agreed. Hopefully, we're far enough from Rec that it may still be
possible to provide feedback either way.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
