modest proposal for simplifying procmod
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath. It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value" so, eg, instead of <param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param> I suggest <param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/> Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement.
I need some time to put it in words (at least coherent ones), but I have a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins. <TEI> ... <persName ref="PId123"> ... </TEI> intended model <model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model> except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs? Puzzled, Magdalena On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Well, this is a different question from the one I asked : the current definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not. I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content! On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
It is a different question, but relevant one. If XPath doesn't cut it, we need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough. On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Do we really want to start inventing new syntax here? That's quite a big change... On 22/01/16 13:17, Magdalena Turska wrote:
It is a different question, but relevant one. If XPath doesn't cut it, we need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough.
On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I know, but this is a class of applications (like displaying biographical note for a person) that is very common and actually crucial, so not accommodating such needs throws a significant portion of projects out of the window. I'd thus either postpone decision if possible, or, rather leave it as it is - in the content of an element, not an attribute as it would cause less turmoil if in the future we need to extend possible contents beyond XPath. On 22 January 2016 at 13:19, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Do we really want to start inventing new syntax here? That's quite a big change...
On 22/01/16 13:17, Magdalena Turska wrote:
It is a different question, but relevant one. If XPath doesn't cut it, we need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough.
On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current
definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have
a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I honestly don't think it would cause any less turmoil to abandon the use of data.xpath here as an attribute value than as element content. Either way it's a fairly major change. But in any case, I'm not planning to change anything in the current proposal for the moment (unless it's demonstrably broken) -- just striving to understand it! While I agree that the use case you identify here is pretty important, there's absolutely nothing in the current proposal to suggest that it has been considered hitherto. So it's definitely in the "desirable enhancement" pile. On 22/01/16 13:32, Magdalena Turska wrote:
I know, but this is a class of applications (like displaying biographical note for a person) that is very common and actually crucial, so not accommodating such needs throws a significant portion of projects out of the window. I'd thus either postpone decision if possible, or, rather leave it as it is - in the content of an element, not an attribute as it would cause less turmoil if in the future we need to extend possible contents beyond XPath.
On 22 January 2016 at 13:19, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Do we really want to start inventing new syntax here? That's quite a big change...
On 22/01/16 13:17, Magdalena Turska wrote:
It is a different question, but relevant one. If XPath doesn't cut it, we need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough.
On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current
definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have
a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I could use a briefing (and I'll read up on it myself, but anything folks want to add here would be really helpful) on how we recommend accommodating the reach into other files (for referencing external personography files, for example) in ODD and schema processing: Do we have room to define variables pointing to external files here? Like I mentioned, I actually write a separate Schematron file to deal with this sort of thing, and I probably shouldn't have to do that but I've had trouble with getting ODD to generate functioning Schematron when I've tried to embed those rules in ODD. I'm sure I'm missing something, but I can get such rules and pointing to work easily when I'm not trying to incorporate them into an ODD but just writing a separate Schematron file. Syd and I were recently tinkering with this, and I hope it's a topic worth broaching here, in connection with Lou's question, in case anyone has some ideas. Thanks, Elisa On Fri, Jan 22, 2016 at 8:37 AM, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I honestly don't think it would cause any less turmoil to abandon the use of data.xpath here as an attribute value than as element content. Either way it's a fairly major change. But in any case, I'm not planning to change anything in the current proposal for the moment (unless it's demonstrably broken) -- just striving to understand it!
While I agree that the use case you identify here is pretty important, there's absolutely nothing in the current proposal to suggest that it has been considered hitherto. So it's definitely in the "desirable enhancement" pile.
On 22/01/16 13:32, Magdalena Turska wrote:
I know, but this is a class of applications (like displaying biographical note for a person) that is very common and actually crucial, so not accommodating such needs throws a significant portion of projects out of the window. I'd thus either postpone decision if possible, or, rather leave it as it is - in the content of an element, not an attribute as it would cause less turmoil if in the future we need to extend possible contents beyond XPath.
On 22 January 2016 at 13:19, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Do we really want to start inventing new syntax here? That's quite a big
change...
On 22/01/16 13:17, Magdalena Turska wrote:
It is a different question, but relevant one. If XPath doesn't cut it, we
need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough.
On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current
definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have
a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath. > > It would be a lot easier to enforce this constraint if the content > were > supplied as an attribute, e.g. "value" > > so, eg, instead of > > <param name="foo">@bar</param> > <param name="default">corr</param> > <param name="lang">ancestor::*/@xml:lang</param> > <param name="place">'foot'</param> > > I suggest > > <param name="foo" value="@bar"/> > <param name="default" value="corr"/> > <param name="lang" value="ancestor::*/@xml:lang"/> > <param name="place" value="'foot'"/> > > > Anyone got strong feelings against this change? The @place example > looks > a > bit dodgy, but otherwise it seems a fairly benign enhancement. > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -- > tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Elisa Beshero-Bondar, PhD Associate Professor of English University of Pittsburgh at Greensburg Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu about.me/ebbondar
You certainly cannot use variables or anything runtime-generated in an XPath. But I thought this level of processing was abstracted out of the processing model? Something like this perhaps <elementSpec ident="persName" mode="change"> <model behaviour="lookup"> <param name="key">@ref</param> <param name="index">doc(persons.xml)//listPerson</param> <param name="return">persName</param> </model> </elementSpec> ? On 22/01/16 13:32, Magdalena Turska wrote:
I know, but this is a class of applications (like displaying biographical note for a person) that is very common and actually crucial, so not accommodating such needs throws a significant portion of projects out of the window. I'd thus either postpone decision if possible, or, rather leave it as it is - in the content of an element, not an attribute as it would cause less turmoil if in the future we need to extend possible contents beyond XPath.
On 22 January 2016 at 13:19, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Do we really want to start inventing new syntax here? That's quite a big change...
On 22/01/16 13:17, Magdalena Turska wrote:
It is a different question, but relevant one. If XPath doesn't cut it, we need more elaborate content model for param, with some mechanism to accommodate variables and then we need markup inside param, so attribute will not be enough.
On 22 January 2016 at 13:15, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current
definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote:
I need some time to put it in words (at least coherent ones), but I have
a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" --
i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Dear Lou and Magdalena, I think I'm with Syd in wondering why it matters to move the content into an attribute. It seems to work just as well either to hold XPath content as element or attribute content, so I am not sure putting it into an attribute value is necessarily better. Magdalena's question interests me as a complicating factor that I'd want to solve with something more than a single XPath line. Maybe <param> isn't the place to set up this level of precision. For this sort of joining that Magdalena describes I tend to apply my own Schematron, which may not be the recommended way to do things...?) Elisa Typeset by hand on my iPad
On Jan 22, 2016, at 8:15 AM, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Well, this is a different question from the one I asked : the current definition says that you have to supply an XPath. If you can write an XPath that does what you want, you're OK, if not, not.
I just want to know whether you agree that supplying the XPath as an attribute value is better than supplying it as content!
On 22/01/16 13:06, Magdalena Turska wrote: I need some time to put it in words (at least coherent ones), but I have a bad feeling about this. Case to ponder: how to express that content for a model should be pulled from some other location matching id of the processed element, so effectively how to do joins.
<TEI> ... <persName ref="PId123"> ... </TEI>
intended model
<model behaviour="note"> <param name="content">doc("persons.xml")//person[@xml:id=***@ref***]</param> </model>
except that I cannot say @ref here, because I mean @ref of persName being processed. Is there any XPath magic to say it? Or would we need some other mechanism to accommodate such jobs?
Puzzled,
Magdalena
On 22 January 2016 at 12:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I have no objection: since we never plan to put markup inside the value of <param> (right?), whether it is an attribute value or content does not matter at all. That said, I cannot fathom why it is easier to enforce that the value of an attribute be macro.xpath vs the content an element be macro.xpath. element param { attribute value { macro.xpath } } element param { macro.xpath } or <attDef ident="value"> <datatype maxOccurs="1" minOccurs="1"> <rng:ref name="macro.xpath"/> </datatype> </attDef> <content> <rng:ref name="macro.xpath"/> </content> or, if using PureODD, change <rng:ref> to <macroRef>. Either way, neither one seems particularly more difficult to do than the other.
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement.
I agree that there's no reason to prefer the attribute value over the content if you're operating in RELAXNG. My preference is probably coloured by the fact that the current ODD processor doesn't translate the macroRef properly: it produces "CDATA" in the DTD rather than "#PCDATA". I havent checked to see what it does for XSD but that's probably defective too. On 22/01/16 13:13, Syd Bauman wrote:
I have no objection: since we never plan to put markup inside the value of <param> (right?), whether it is an attribute value or content does not matter at all. That said, I cannot fathom why it is easier to enforce that the value of an attribute be macro.xpath vs the content an element be macro.xpath.
element param { attribute value { macro.xpath } }
element param { macro.xpath }
or
<attDef ident="value"> <datatype maxOccurs="1" minOccurs="1"> <rng:ref name="macro.xpath"/> </datatype> </attDef>
<content> <rng:ref name="macro.xpath"/> </content>
or, if using PureODD, change <rng:ref> to <macroRef>.
Either way, neither one seems particularly more difficult to do than the other.
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement.
participants (5)
-
Elisa -
Elisa Beshero-Bondar -
Lou Burnard -
Magdalena Turska -
Syd Bauman