Re: RE: Namespace use cases
> Just a quick comment on one of your points, Rick. Delighted. > At 2009-07-11 20:06 +1000, email@example.com wrote: >>The second is the namespaces used for Qnames in element and attribute >>values. XSLT went one way, but I think it is the wrong way because it >>fudges the difference between data and markup. Schematron has explicit >>elements and this has been very smooth: developers don't worry about >>default namespaces, they only need to look in a single place. > > I long regret the Schematron choice of using elements for declaring > namespaces and their prefixes. In every other application of XML I > use the namespace axis and namespace facilities to obtain the > information I need to support XPath addresses that are in attribute > values, Not so. In XSD for example you also need to look up the attributeFormDefault, elementFormDefault, the targetNamespace attribute and whether any imports have namespace attributes. > but for Schematron I have to do something different than for > everything else. So now instead of looking in a single place for > namespaces (the namespace axis) I now have to look in a second place > (the newly-introduced Schematron elements). > > I've always been uncomfortable with that. I do not find it "smooth" at > all. Data is data, not markup. You should not have to alter the data in order to fit in with the markup being used. There is nothing in the Namespaces spec that says it should be applied for data, and there are no schema languages that even allow this to be declared in a transparent fashion. DOM didn't even support namespaces. XSLT1's namespace implementations were unreliable. XSLT has adopted a different system again. In Schematron you know where to find the namespaces no matter what version of DOM, XSLT 1, XSLT2 etc you are you using. And you don't need to look at any scope or imports or defaults to figure things out. And, more importantly, there is no mucking about with default namespaces. By keeping the data and the markup strictly separate, there is no problem with using the default namespace for the schema elements and making constraints on data with no namespace. This cannot be done otherwise. For example: <schema ... xmlns="http://purl.oclc.org/dsdl/schemaatron"> ... <rule context="html"> <assert test="head">And html element should have a head</assert> </rule> </schema> Why is the namespace used for a qname in data any different from, say, the units of measure used in a document? It would be perfectly feasible to instead having width="1 cm" having width="1" plus units="cm" then allowing that to find the units you should look up ancestor-or-self::*[@units]/@units --indeed, SVG has all sorts of scoping like this though not exactly this-- but it introduces an unnecessary generality. Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format