On Thu, Apr 28, 2011 at 12:54 PM, Michele R Combs <[log in to unmask]> wrote:
> Do you by chance have a comparable list of changes that had to be made to the style sheet and/or your output processing (other than the obvious ones to accommodate the changes to the EAD) ?  For example, we use Saxon as our XSLT processor and not all versions of Saxon are schema-aware (, so for us it would mean upgrading to a different version, or to something else.

In my understanding, schema-aware processing really only is an issue
if 1) you're using XSLT 2.0 and 2) you need access to schema
information. From the XSLT 2.0 specification

The conformance rules for XSLT 2.0, defined in 21 Conformance,
distinguish between a basic XSLT processor and a schema-aware XSLT
processor. As the names suggest, a basic XSLT processor does not
support the features of XSLT that require access to schema
information, either statically or dynamically. A stylesheet that works
with a basic XSLT processor will produce the same results with a
schema-aware XSLT processor provided that the source documents are
untyped (that is, they are not validated against a schema). However,
if source documents are validated against a schema then the results
may be different from the case where they are not validated. Some
constructs that work on untyped data may fail with typed data (for
example, an attribute of type xs:date cannot be used as an argument of
the substringFO function) and other constructs may produce different
results depending on the data type (for example, given the element
<product price="10.00" discount="2.00"/>, the expression @price gt
@discount will return true if the attributes have type xs:decimal, but
will return false if they are untyped.

It basically depends on how strongly your data is typed. If you're
just looking to migrate from DTD-compliant to schema-compliant EAD, I
don't think you'll have much of an issue.*

* Feel free to correct me if I'm wrong.

Mark A. Matienzo
Digital Archivist, Manuscripts and Archives
Yale University Library