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]

RE: XSL-List Digest V3 #1175


Coming from an a relational DB and programming background, xsl schema design
seems relatively mature.

XSD may not be appropriate to XSLT in it's current state of development, but
it is very relevant to code I use in other environments.
There may be sense in holding development for a while, but I would be most
upset to lose the tool entirely.

I can not agree that just because it's difficult to teach, that it should be
dropped.




Given that an XML document may have an attribute indicating the schema
location, and given that that schema may be an XSD (ie XML) file - it
strikes me as entirely possible to create a callable (library?) XSLT
template to read that schema document - and thus to populate default
entities in the live document.
The whole thing can be pure XML/XSLT.

ERH - do you have a student looking for a project?  It would not be trivial.


Cheers

Robert Stuart



From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: <xsl-list@lists.mulberrytech.com>
Cc: <xsl-editors@w3.org>
Sent: Saturday, October 13, 2001 10:09 AM
Subject: Re: Schemas in XSLT 2.0 (Was: Re: [xsl] keys and idrefs - XSLT2
request?)


> At 4:12 PM +0100 10/10/01, Jeni Tennison wrote:
>
> >So, the first question is whether XSLT 2.0 should mandate support of
> >XML Schema within XSLT processors (i.e. you've got to be able to
> >validate against XML Schema in order to be a conformant XSLT 2.0
> >processor).
>
> I propose something even more radical. Drop schemas completely from XPath
2.0/XSLT 2.0. First do everything that can be done without considering
schemas; e.g. better grouping, multiple document output, XHTML output
method, text inclusions, explicit matching of default namespaces, etc.  This
could be implemented and finished much more quickly, and would be useful in
and of itself.
>
> Then, and only then, begin work on XPath 3.0/XSLT 3.0 which would consider
only issues relevant to PSVI support. By this time we might actually have
some schema aware APIs to build on top of.
>
> Furthermore this would also make XSLT 2.0 and 3.0 a lot easier to teach
and learn because it would be more obvious what depended on what. You
wouldn't, for example, have to learn schemas in order to support multiple
output documents.
> --
>
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
[snip]

 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]