This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: James Clark on Schema



>> * It is unreasonable to expect a W3C specification (such as XQuery)
to 
>> adopt as its basis a data model not under control of the W3C, when
there >>is 
>> a W3C data model that is acceptable.
>> ...
>>  To hope that the various Working Groups will "see 
>> the light" and choose to use a schema-like facility defined outside
the >>W3C 
>> is highly unlikely.  

It might be unlikely but there a number of different xml-based schema
languages out there, as these are also based on W3C standards - such as
xml :) - I can't help but think that to build one's own schema language,
that most of the people familiar with other W3C standards seem to
actively dislike, and then to start requiring other popular standards
support their ugly cousin is a recipe for driving us all to Perl and
regular expressions(and I hate Perl). If a prior standard should be made
to support validation methodologies then it should do it at a far higher
level of abstraction, this is to say that just as there was an xml
infoset there should be a schema infoset, and I think the rule should be
the schema infoset could not be any longer than the xml, so as to
prevent another evil monster Spec from developing and terrorizing
humanity.
When I say the above about schema infoset I am partially facetious, but
I have argued to no great success in the past for being able to query
against some sort of abstract validator, and the specific validator be
defined by implementor, and I still think this would be preferable for
me at least, and as I consider myself a representative, average
developer I suppose it would be preferable to the community. This might
not be as extremely useful as being able to query against all the
possible datatypes and what-not that an xml-schema specific requirement
would allow, but I doubt it would be as deadly either.

David Carlisle wrote:
>I have never argued that XPath2 should be based on Relax NG, what I
have
>argued is that it shouldn't be based so closely on W3C Schema. In
>particular, concentrating for now on the simple types rather than
>complex types (element structure) it should not have accumulated
>the mass of numeric, date and string types. They make no sense to be
>hardwired into a query language aimed at generic XML documents.
>No fixed set of random types will ever be of any real use in an XML
>context as most of the documents are generated for reasons unconnected
>with XQuery/XPath. An XML Query language has to be able to cope with
>whatever's out there it can't just invent a world view and pretend that
>all documents will conform.  Having a float and an integer type
(already
>an extension to XPath 1) makes sense; having byte and friends is just
>slavish devotion to the schema spec. Dropping them does not mean
>abandoning W3C and following James into the uncharted waters of ISO. It
>just means making XPath usable again. A small section of a revised
>XPath2 document mapping the primitive W3C schema types into XPath would
>be all that's required.

Okay how about this: Oasis donates RELAX NG to the W3C, they immediately
rename it Xml Schema 2.0(either that or Topologi donates schematron,
that's what I want) :) and start working on Xml Schema 3, in this way
they could act as though they haven't lost the hearts and minds of the
community and declare marketing victory. 
Then again maybe they create an xml schemas working group which realizes
the need for various schema languages and start marketing Xml Schema as
one especially suited to the needs of ... - ?


>If you want an integer less than 0 and 2^8  you should be able to
>express that in the same way as an integer between 0 and 12, 
>why have a special "byte type". At first sight it doesn't appear too
bad,
>as if you don't need it don't use it and if you do need it it might
save
>a keystroke or two, but the net effect of having dozens of pointless
>primitive types in the language is that the language has an exponential
>explosion in the complexity of its casting rules and functions, and is
>impossible to learn: I challenge anyone to list the full set of
primitive
>XPath2 types off the top of their head, without reference to the spec
>(F&O or schema).

Yeah and what if someone has learned something different than you. What
if you come from a language where some of these types don't exist and
someone else comes from a language where they do. What's the chance that
their xslt 2.0 will depend on datatypes similar to ones they are used to
analyzing? Pretty high I bet.

>Support for complex types also massively complicates the specification
>for little to no benefit. If you want to find all children elements
that
>have a parent parent, it is far more natural to use XPath parent/child
I
>see no occasions when it would be more natural (In an Xpath context) to
>define a schema type for that construct and and then query on the
>type. This comment is not particularly against W3C Schema it is a
>comment on Schema in general with respect to XPath. (Schema are fine
for
>their main use of constraining authoring and checking that a document
is
>correctly authored. But querying is something different)

>A schema type is basically just a named content model in a DTD (if you
>view DTDs as a schema language with non-XML syntax) As far as I can
>tell no one ever asked in an XPath or XSLT context to be able to query 
>by a particular content model without having to specify the element
>name When is this supposed to be useful? (None of the XQuery use cases
>show any use for this facility

other than in the case of generic computational stylesheets I can think
of none, and as computational stylesheets are a small subset of the
whole production of stylesheets worldwide I assume it would be better to
leave it out. At any rate computations of any worth would probably be
suited to a particular content model. 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]