I gave up trying to get the HTML to look nice for the moment and went
back to testing my purified datatypes, which threw up the following oddity.
The attribute @prefix on <elementSpec> is currently defined (in RNG) as
follows
rng:choice
rng:value/
There are definitely cases in XSLT where you need to explicitly bind a prefix to the empty namespace. I have instances in my own code. If the xpath-default-namespace is TEI, and you have some no-namespace stuff from another source to handle simultaneously, it's the clearest approach. Whether that applies to this context or not I don't know. Cheers, Martin On 15-10-11 09:36 AM, Lou Burnard wrote:
I gave up trying to get the HTML to look nice for the moment and went back to testing my purified datatypes, which threw up the following oddity.
The attribute @prefix on <elementSpec> is currently defined (in RNG) as follows
(or in compact form:
attribute prefix { "" |data.xmlName http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.xmlName.html }? )
I*think* this is so that you can distinguish (say) <elementSpec ident="foo" prefix=""/> from <elementSpec ident="foo" > but my question is WHY WOULD YOU WANT TO DO THAT?
If no-one can come up with a persuasive case where this distinction might be necessary, I'd rather change this to <dataRef key="teidata.xmlName"/> than go to the trouble of defining a new <dataSpec> for this case.
If I make that simplification, prefix="" would then be illegal; but wouldn't it be just as effective to say that if no prefix is supplied the implication is that the prefix is null?
I believe (perhaps incorrectly so) that we deliberately allow @prefix= of, say, <elementSpec> to be null so that it can be used to explicitly override the prefix="duck_" of its parent <schemaSpec>. (Because of no @prefix is supplied, the presumption is it is inherited.) Although I have to admit I'm not sure why one would want to do that.
I gave up trying to get the HTML to look nice for the moment and went back to testing my purified datatypes, which threw up the following oddity.
The attribute @prefix on <elementSpec> is currently defined (in RNG) as follows
(or in compact form:
attribute prefix { "" |data.xmlName http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.xmlName.html }? )
I*think* this is so that you can distinguish (say) <elementSpec ident="foo" prefix=""/> from <elementSpec ident="foo" > but my question is WHY WOULD YOU WANT TO DO THAT?
If no-one can come up with a persuasive case where this distinction might be necessary, I'd rather change this to <dataRef key="teidata.xmlName"/> than go to the trouble of defining a new <dataSpec> for this case.
If I make that simplification, prefix="" would then be illegal; but wouldn't it be just as effective to say that if no prefix is supplied the implication is that the prefix is null?
OK, thanks, that's probably good enough to warrant a new data spec... On 11/10/15 17:44, Syd Bauman wrote:
I believe (perhaps incorrectly so) that we deliberately allow @prefix= of, say, <elementSpec> to be null so that it can be used to explicitly override the prefix="duck_" of its parent <schemaSpec>. (Because of no @prefix is supplied, the presumption is it is inherited.)
Although I have to admit I'm not sure why one would want to do that.
I gave up trying to get the HTML to look nice for the moment and went back to testing my purified datatypes, which threw up the following oddity.
The attribute @prefix on <elementSpec> is currently defined (in RNG) as follows
(or in compact form:
attribute prefix { "" |data.xmlName http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.xmlName.html }? )
I*think* this is so that you can distinguish (say) <elementSpec ident="foo" prefix=""/> from <elementSpec ident="foo" > but my question is WHY WOULD YOU WANT TO DO THAT?
If no-one can come up with a persuasive case where this distinction might be necessary, I'd rather change this to <dataRef key="teidata.xmlName"/> than go to the trouble of defining a new <dataSpec> for this case.
If I make that simplification, prefix="" would then be illegal; but wouldn't it be just as effective to say that if no prefix is supplied the implication is that the prefix is null?
participants (3)
-
Lou Burnard -
Martin Holmes -
Syd Bauman