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: basic question about xpath support of xml schema



>> was just wondering, have been skimming through the xml path
>> language 2.0 wd
>> and haven't found exactly where it's described how the
>> processors knows what
>> schema it should work with.

>That's an excellent question, and the reason you haven't found it is that
>it's not really there. The XPath spec says that a set of named type
>definitions must be made available by the host language as part of the
>static context. The XSLT spec has an open issue as to how this part of the
>context should be populated. What's likely to appear is some kind of
><xsl:import-schema> declaration to associate one or more schemas with a
>stylesheet. For an indication of how this might work, see the "import
>schema" clause in the XQuery prolog.

Good! cause this brings me to the real thing I wanted to ask about :)
I have reservations about the use of xml schema with xpath, in that xml
schema is not right for every situation.
I'll point to James Clark and his observation that he could never quite
match the structure of xslt in xml schema, hence his making of TREX. It
could be interpreted by some as a political move to force adoption of xml
schema; now in this situation I'm arguing against my own economic benefit
since I can write xml schema, using a text editor not just extensibility,
and it's complexity will no doubt benefit me as it's requirement for
projects increases, but I'd prefer a less schema specific structure, if  for
example one had an xsl:validator element, and an xf:validator(),  then it
could be left to implementors what validating mechanism they wanted to
support. Some people might argue that this would create problems translating
from processor to processor but I doubt it as I think most implementors
would support xml schema anyway. What it could maybe do is allow situations
like Topologi licenscing msxml, building their own processor on top that has
support for schematron built into it, as well as whatever schemas that msxml
would support, which means of course xml schema and xdr.

Now I admit I'm not trained or very knowledgable about building parsers or
processors, no lex/yacc here, so this will probably come off stupid, but I
thought it would work nicely if an <xsl:validator href="myschema.xsd"/>
loaded in the schema and then when your xslt had <xsl:template
match="something"></xsl:template> the validator would from <xsd:element
name="something" type="my:somethingType"/>
know to go to <xsd:simpleType name="somethingType">

			</xsd:simpleType>

then you could write <xsl:if test="xf:validator(.,true)"></xsl:if> with the
understanding that validator returns a boolean true false, either the value
you feed it is valid or not. in this case we're saying is the node we're in
valid by the schema, but we could also have something like
xf:validator($doc,false) where doc is an external document called by the
document().

It would probably be nice to have a couple other functions one could call,
of course.

Now imagine if this were applied to Relax NG, we could then have a schema
that did apply to xslt, or a schematron specifically written to describe
certain rules for how we want our xslts authored.

I say this because one of the harder things to do is to generate xslt with
xslt, but you can't have a schema that describes the whole of it's
structure, therefore you wouldn't be able to use xsl:import-schema
href="xslt.xsd" and derive any benefit from it, I think.

Anyway, I'm sure some of my reservations or ideas are just totally
wrong-headed here, so I'd like comment pointing out where I'm wrong.










 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]