[sc34wg3] Almost arbitrary markup in resourceData
Freese, Eric D. (LNG-DAY)
sc34wg3@isotopicmaps.org
Thu, 13 Nov 2003 09:05:02 -0500
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3A9EF.21AF0724
Content-Type: text/plain;
charset="iso-8859-1"
Thanks Aad! This seems reasonable. It is similar to how SVG does its
extension mechanism. In SVG, you add any new markup to the predefined
entities in the doctype declaration for the document. I assume that there
is similar functionality in RELAX-NG. This works for me, because the XTM
document is still valid XML.
I really like the rules about the TM owner providing the guidance for
processing the arbitrary XML. If you're sending stuff like this out, you
should be documenting it. Of course it would be up to the person using the
topic map to decide if they want to honor the guidance, but at that point if
they don't it is "buyer beware". We should probable make it possible to
declare which of the pieces are to be removed tags and all and which of the
others are to remove just the tags. OR make one action the default and have
a way of declaring the exceptions. A list of XPaths might be a good way of
doing this (//resourceData/myTag).
The one question for rule #3 is "What assumptions do I make in preparing the
stylesheet?" Do I assume presentation (to XHTML?) or some other processing
(transformation to some industry standard)? If this rule were adopted,
there would need to be some clarification as to the base assumptions of the
provided stylesheet.
-----Original Message-----
From: Aad Kamsteeg [mailto:a.kamsteeg@diderottrack.nl]
Sent: Thursday, November 13, 2003 3:37 AM
To: sc34wg3@isotopicmaps.org
Cc: 'Freese, Eric D. (LNG-DAY) '
Subject: Re: [sc34wg3] Almost arbitrary markup in resourceData
I like to chip in on this discussion.
My personal view on this is in line with both sentiments expressed in this
discussion. I think on one hand that "proprietary content" is a application
standard like TM is awkward and could be ugly as well. On the other hand I
know that a way to set a standard to ones own hand, is something that
probably would make a part of the user community quite happy. Besides this I
think that standards should be open as possible, in any case because a
"committee" of any kind cannot foresee all possible usage scenario's.
So I came up with the following proposal in order to see if this could be a
way to solve this.
Just allow for a proprietary extension to the schema, but only in a
formalized way. In terms of RelaxNG: add an empty define (notAllowed) for
the three XTM elements so users (rather maintainers) of a Topic Map can
define their own additional markup by extending the schema in those parts
only.
When a Topic Maps owner decides to do so, the consequences are entirely his.
The standard should give some rules in order to at least state a proper
warning to (ignorant) adopters of that specific TM.
It must me made clear for any other party who is allowed (or granted) to use
the TM in question. As a provision for that purpose an idea could be to add
an optional atribute for the root-element that states that this TM has a
proprietary extension (so all are warned).
The standard should state clearly (normative) that when an extension is used
this attribute is mandatory.
Some guiding rules could be added in addition to this:
- The owner of an extended TM is required to publish the extension in cases
where this TM is made public or is to be shared with others.
- The owner of an extended TM is required to publish an instruction what the
preferred way of resolving this additional mark-up is in a situation where
the extension can not be applied, default rules could be either:
-- remove the proprietary markup and its content (for things like SVG and
Math-ML the most likely solution)
-- remove the proprietay markup and keep the textual bits, (most likely for
added mark-up like <b> or <em>).
- Further more the standard could urge the owner of an extended TM to supply
a sufficient ruleset (could be in the form of a XSLT stylesheet (??) how to
handle the proprietory mark-up if others want to keep (and use) the added
value that is archieved with this extension.
This way the responsibillity for extended TM's is entirely for the party
that created the TM, not for the standards organisation. The standard does
provide sufficient rules to handle these exceptional (?) cases as decent as
possible.
:-) Aad
PS. I agree with using RelaxNG as the normative schema language. I have
quite some experience in using Relax because, as consultants / designers of
schema we use Relax in all situations. We have some additional rules in
order to enable reliable conversion towards a DTD. If interested I don't
mind sharing this (and the XSLT stylesheets that do the job) with you.
Mason, James David (MXM) wrote:
XHTML+MathML might get a lot of the presentation functionality I need, but
certainly only that functionality, not the actual tags I want to use: XHTML
certainly isn't any of the tag sets we use for classification guides, which
identify all sorts of things never thought of in HTML (or the old IBM DCF
Starter Set, on which it is based). And we carry lots of attributes that
have no counterparts in HTML on the tags that otherwise map reasonably well.
Jim
-----Original Message-----
From: Freese, Eric D. (LNG-DAY)
To: ' sc34wg3@isotopicmaps.org <mailto:sc34wg3@isotopicmaps.org> '
Sent: 11/12/2003 8:57 AM
Subject: RE: [sc34wg3] Almost arbitrary markup in resourceData
As I said (when the 3rd time was the charm) - No, XHTML is not enough
for my
requirements because we want to use full (real) XML with our own
semantic
markup. I doubt XHTML would even meet a 20% usefulness level for us.
Anyone else?
-----Original Message-----
From: sc34wg3-admin@isotopicmaps.org
<mailto:sc34wg3-admin@isotopicmaps.org>
[ mailto:sc34wg3-admin@isotopicmaps.org
<mailto:sc34wg3-admin@isotopicmaps.org> ]On Behalf Of Murray Altheim
Sent: Wednesday, November 12, 2003 7:58 AM
To: sc34wg3@isotopicmaps.org <mailto:sc34wg3@isotopicmaps.org>
Subject: Re: [sc34wg3] Almost arbitrary markup in resourceData
Patrick Durusau wrote:
Eric,
Freese, Eric D. (LNG-DAY) wrote:
<snip>
I am speaking from the front lines of the user community,
not the tool
vendor community, not the acedemic community. I'm claiming
my stake as part
of the target market - the people who want to make money
using the tools and
standard as opposed to those implementing or studying.
Ouch! Or as Charley Brown would say, "He nicked me with a nyah!" ;-)
The academic community has suffered at the hands of
standards bodies
that prefer texts that are dumbed down until they meet
capricious limits
on parsing/processing. Well, the users in the academic
community at any
rate.
I think Eric's point is well taken and the various parts of
the topic
map standard need to take it into account. Standards that insure
information is interchangeable but that do not meet the
needs of users
are interesting, but irrelevant.
As Eric and others have suggested, we are not faced with
choosing either
interchange or usefulness. Both are possible in the topic
maps standard,
but only if we show some imagination and ingenuity in devising a
solution that meets both requirements. To choose one
without the other
is a recipe for failure.
Well, the sixth time is a charm: would the XHTML+XTM DTD meet the
80/20 point? That's the question. Can we avoid arbitrary markup by
providing a specific hybrid that solves the problem for 80% of the
users who need extended abilities? As I've said, I'm even willing
to do that work if it means avoiding arbitrary markup in a standard,
which I will continue to maintain is a nonsequitor.
Murray
..............................................................
.............
Murray Altheim
http://kmi.open.ac.uk/people/murray/ <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
.
Entitled Continuing Collateral Damage: the health and environmental
costs of war on Iraq, the report estimates that between 22,000 and
55,000 people - mainly Iraqi soldiers and civilians - died
as a direct
result of the war.
http://news.bbc.co.uk/1/hi/world/middle_east/3259489.stm
<http://news.bbc.co.uk/1/hi/world/middle_east/3259489.stm>
Entitled Continuing Collateral Damage? ...a euphemism for BushCo.
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org <mailto:sc34wg3@isotopicmaps.org>
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
<http://www.isotopicmaps.org/mailman/listinfo/sc34wg3>
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org <mailto:sc34wg3@isotopicmaps.org>
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
<http://www.isotopicmaps.org/mailman/listinfo/sc34wg3>
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org <mailto:sc34wg3@isotopicmaps.org>
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
<http://www.isotopicmaps.org/mailman/listinfo/sc34wg3>
--
*********************************************
Diderot Track bv - Consultants in Information
Phone: +31 (0) 70 3966305
Fax: +31 (0) 70 3966304
Email: a.kamsteeg@diderottrack.nl <mailto:a.kamsteeg@diderottrack.nl>
Web: www.diderottrack.nl <http://www.diderottrack.nl>
*********************************************
------_=_NextPart_001_01C3A9EF.21AF0724
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>
<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=130204013-13112003>Thanks
Aad! This seems reasonable. It is similar to how SVG does its
extension mechanism. In SVG, you add any new markup to the predefined
entities in the doctype declaration for the document. I assume that there
is similar functionality in RELAX-NG. This works for me, because the XTM
document is still valid XML.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=130204013-13112003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=130204013-13112003>I
really like the rules about the TM owner providing the guidance for
processing the arbitrary XML. If you're sending stuff like this out, you
should be documenting it. Of course it would be up to the person using the
topic map to decide if they want to honor the guidance, but at that point if
they don't it is "buyer beware". We should probable make it possible to
declare which of the pieces are to be removed tags and all and which
of the others are to remove just the tags. OR make one action the default
and have a way of declaring the exceptions. A list of XPaths might be a
good way of doing this (//resourceData/myTag).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=130204013-13112003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=130204013-13112003>The
one question for rule #3 is "What assumptions do I make in preparing the
stylesheet?" Do I assume presentation (to XHTML?) or some other processing
(transformation to some industry standard)? If this rule were
adopted, there would need to be some clarification as to the base assumptions of
the provided stylesheet.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Aad Kamsteeg
[mailto:a.kamsteeg@diderottrack.nl]<BR><B>Sent:</B> Thursday, November 13,
2003 3:37 AM<BR><B>To:</B> sc34wg3@isotopicmaps.org<BR><B>Cc:</B> 'Freese,
Eric D. (LNG-DAY) '<BR><B>Subject:</B> Re: [sc34wg3] Almost arbitrary markup
in resourceData<BR><BR></FONT></DIV>I like to chip in on this
discussion.<BR>My personal view on this is in line with both sentiments
expressed in this discussion. I think on one hand that "proprietary content"
is a application standard like TM is awkward and could be ugly as well. On the
other hand I know that a way to set a standard to ones own hand, is something
that probably would make a part of the user community quite happy. Besides
this I think that standards should be open as possible, in any case because a
"committee" of any kind cannot foresee all possible usage
scenario's.<BR><BR>So I came up with the following proposal in order to see if
this could be a way to solve this.<BR><BR>Just allow for a proprietary
extension to the schema, but only in a formalized way. In terms of RelaxNG:
add an empty define (notAllowed) for the three XTM elements so users (rather
maintainers) of a Topic Map can define their own additional markup by
extending the schema in those parts only.<BR><BR>When a Topic Maps owner
decides to do so, the consequences are entirely his. The standard should give
some rules in order to at least state a proper warning to (ignorant) adopters
of that specific TM.<BR>It must me made clear for any other party who is
allowed (or granted) to use the TM in question. As a provision for that
purpose an idea could be to add an optional atribute for the root-element that
states that this TM has a proprietary extension (so all are warned).<BR>The
standard should state clearly (normative) that when an extension is used this
attribute is mandatory.<BR><BR>Some guiding rules could be added in addition
to this:<BR>- The owner of an extended TM is required to publish the extension
in cases where this TM is made public or is to be shared with others.<BR>- The
owner of an extended TM is required to publish an instruction what the
preferred way of resolving this additional mark-up is in a situation where the
extension can not be applied, default rules could be either:<BR>-- remove the
proprietary markup and its content (for things like SVG and Math-ML the most
likely solution)<BR>-- remove the proprietay markup and keep the textual bits,
(most likely for added mark-up like <b> or <em>).<BR>- Further
more the standard could urge the owner of an extended TM to supply a
sufficient ruleset (could be in the form of a XSLT stylesheet (??) how to
handle the proprietory mark-up if others want to keep (and use) the added
value that is archieved with this extension.<BR><BR>This way the
responsibillity for extended TM's is entirely for the party that created the
TM, not for the standards organisation. The standard does provide sufficient
rules to handle these exceptional (?) cases as decent as possible.<BR><BR>:-)
Aad<BR><BR>PS. I agree with using RelaxNG as the normative schema language. I
have quite some experience in using Relax because, as consultants / designers
of schema we use Relax in all situations. We have some additional rules in
order to enable reliable conversion towards a DTD. If interested I don't mind
sharing this (and the XSLT stylesheets that do the job) with
you.<BR><BR>Mason, James David (MXM) wrote:<BR>
<BLOCKQUOTE
cite=midA393351AAE080640999E5935BCE9FDA101B718CF@exchange10.y12.doe.gov
type="cite"><PRE wrap=""> XHTML+MathML might get a lot of the presentation functionality I need, but
certainly only that functionality, not the actual tags I want to use: XHTML
certainly isn't any of the tag sets we use for classification guides, which
identify all sorts of things never thought of in HTML (or the old IBM DCF
Starter Set, on which it is based). And we carry lots of attributes that
have no counterparts in HTML on the tags that otherwise map reasonably well.
Jim
-----Original Message-----
From: Freese, Eric D. (LNG-DAY)
To: '<A class=moz-txt-link-abbreviated href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</A>'
Sent: 11/12/2003 8:57 AM
Subject: RE: [sc34wg3] Almost arbitrary markup in resourceData
As I said (when the 3rd time was the charm) - No, XHTML is not enough
for my
requirements because we want to use full (real) XML with our own
semantic
markup. I doubt XHTML would even meet a 20% usefulness level for us.
Anyone else?
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:sc34wg3-admin@isotopicmaps.org">sc34wg3-admin@isotopicmaps.org</A>
[<A class=moz-txt-link-freetext href="mailto:sc34wg3-admin@isotopicmaps.org">mailto:sc34wg3-admin@isotopicmaps.org</A>]On Behalf Of Murray Altheim
Sent: Wednesday, November 12, 2003 7:58 AM
To: <A class=moz-txt-link-abbreviated href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</A>
Subject: Re: [sc34wg3] Almost arbitrary markup in resourceData
Patrick Durusau wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Eric,
Freese, Eric D. (LNG-DAY) wrote:
<snip>
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I am speaking from the front lines of the user community,
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">not the tool
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">vendor community, not the acedemic community. I'm claiming
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">my stake as part
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">of the target market - the people who want to make money
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">using the tools and
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">standard as opposed to those implementing or studying.
</PRE></BLOCKQUOTE><PRE wrap="">Ouch! Or as Charley Brown would say, "He nicked me with a nyah!" ;-)
The academic community has suffered at the hands of
</PRE></BLOCKQUOTE><PRE wrap="">standards bodies
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">that prefer texts that are dumbed down until they meet
</PRE></BLOCKQUOTE><PRE wrap="">capricious limits
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">on parsing/processing. Well, the users in the academic
</PRE></BLOCKQUOTE><PRE wrap="">community at any
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">rate.
I think Eric's point is well taken and the various parts of
</PRE></BLOCKQUOTE><PRE wrap="">the topic
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">map standard need to take it into account. Standards that insure
information is interchangeable but that do not meet the
</PRE></BLOCKQUOTE><PRE wrap="">needs of users
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">are interesting, but irrelevant.
As Eric and others have suggested, we are not faced with
</PRE></BLOCKQUOTE><PRE wrap="">choosing either
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">interchange or usefulness. Both are possible in the topic
</PRE></BLOCKQUOTE><PRE wrap="">maps standard,
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">but only if we show some imagination and ingenuity in devising a
solution that meets both requirements. To choose one
</PRE></BLOCKQUOTE><PRE wrap="">without the other
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">is a recipe for failure.
</PRE></BLOCKQUOTE><PRE wrap="">Well, the sixth time is a charm: would the XHTML+XTM DTD meet the
80/20 point? That's the question. Can we avoid arbitrary markup by
providing a specific hybrid that solves the problem for 80% of the
users who need extended abilities? As I've said, I'm even willing
to do that work if it means avoiding arbitrary markup in a standard,
which I will continue to maintain is a nonsequitor.
Murray
..............................................................
.............
Murray Altheim
<A class=moz-txt-link-freetext href="http://kmi.open.ac.uk/people/murray/">http://kmi.open.ac.uk/people/murray/</A>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
.
Entitled Continuing Collateral Damage: the health and environmental
costs of war on Iraq, the report estimates that between 22,000 and
55,000 people - mainly Iraqi soldiers and civilians - died
as a direct
result of the war.
<A class=moz-txt-link-freetext href="http://news.bbc.co.uk/1/hi/world/middle_east/3259489.stm">http://news.bbc.co.uk/1/hi/world/middle_east/3259489.stm</A>
Entitled Continuing Collateral Damage? ...a euphemism for BushCo.
_______________________________________________
sc34wg3 mailing list
<A class=moz-txt-link-abbreviated href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</A>
<A class=moz-txt-link-freetext href="http://www.isotopicmaps.org/mailman/listinfo/sc34wg3">http://www.isotopicmaps.org/mailman/listinfo/sc34wg3</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->_______________________________________________
sc34wg3 mailing list
<A class=moz-txt-link-abbreviated href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</A>
<A class=moz-txt-link-freetext href="http://www.isotopicmaps.org/mailman/listinfo/sc34wg3">http://www.isotopicmaps.org/mailman/listinfo/sc34wg3</A>
_______________________________________________
sc34wg3 mailing list
<A class=moz-txt-link-abbreviated href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</A>
<A class=moz-txt-link-freetext href="http://www.isotopicmaps.org/mailman/listinfo/sc34wg3">http://www.isotopicmaps.org/mailman/listinfo/sc34wg3</A>
</PRE></BLOCKQUOTE><BR><PRE class=moz-signature cols="72">--
*********************************************
Diderot Track bv - Consultants in Information
Phone: +31 (0) 70 3966305
Fax: +31 (0) 70 3966304
Email: <A class=moz-txt-link-abbreviated href="mailto:a.kamsteeg@diderottrack.nl">a.kamsteeg@diderottrack.nl</A>
Web: <A class=moz-txt-link-abbreviated href="http://www.diderottrack.nl">www.diderottrack.nl</A>
*********************************************
</PRE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C3A9EF.21AF0724--