[Home] [By Thread] [By Date] [Recent Entries]
Jon Noring said: > Melvin Chin wrote: >> Ben Trafford wrote: > >>> Because there are dozens of different ways to declare a link in >>> different XML applications. DocBook does it differently than XHTML, >>> CML does it differently (and for different purposes) than DocBook, >>> etc. ... As soon as we specify links via a rigid vocabulary that must >>> exist in the markup, we lose interoperability between >>> different XML applications. > >> I see where you're coming. I was looking at your suggestion of >> requiring XML representation from the point of view of practicality. >> With my comment to subsequent point in mind, a link is needed if it is >> needed by data processing or representational demands due to >> inherent need of the problem. But if a link is need only if in a >> specified format, eg. XML format, then its applicable usage would be >> much more specialised... [snip] >> >> Ok, if you're talking specifically about XLink, I'll ask if another >> worthy candidate of equal generality in application areas and >> flexibility is available as an alternative for this "data about >> relationships" representation. If so, we can compare merits and pick >> the better or best one and refine it. If not, then XLink would be the >> only default best candidate and it would be better to channel energy >> to make it "cover the necessary aspects" that you're >> concerned with. > > I've been following this thread with great interest. Like Ben, I'm > involved in projects focused on the use of XML to represent digital > publications such as books, periodicals, etc. These digital > publications will include hypertext links and embedded objects. > > And we are both interested in how one can enable XML-based publication > frameworks (exemplified by OEBPS and the proposed OpenReader) to allow > publishers to use "roll-their-own" XML vocabularies to represent > textual content. This is just the field where i am working now. We wait to publish rich datuments with scientific content. We do not use CML, MathML, or XHTML for descriptive markup but are developing our own language. Instead using XML off-line being served as XHTML + p-MathML at the client side and loosing all information richness (this is basically the PDF approach so critized by Murray Rust). We wait to serve directly the source datuments to users. A first problem we find is on adding simple links to referenced material in the XML. Xlink does not work on the browser side except for Mozilla if i remember correctly. Therefore, we are using embbebded <a> with corresponding namespace. > This issue goes beyond just hypertext linking and digital object > inclusion. A perusal of the (relatively) semantic-poor XHTML > vocabulary shows various semantics we'd like to recognize in arbitrary > XML markup. And if we look at the semantically-richer TEI and DocBook > vocabularies, the list of possible semantic items greatly expands. > > The accessibility community is also very interested in this topic -- in > a nutshell, the accessibility community is scared stiff of allowing > "arbitrary" XML markup in digital publications until some required > mechanism is designed so the semantics of arbitrary markup (at least > semantics of interest to the accessibility community) can be > "communicated" to user agents. > > [For example, the accessibility community would like to know if > certain content is an abbreviation (XHTML <abbr>), a quote (XHTML > <blockquote> and <q>), some type of computer code fragment (XHTML > <code>, <var>, etc.), and so forth.] Yes, this is great problem also. Even using "accesibility oriented" markups as MathML, this is far from being solved in minimal needs. > Based on this, I propose a two-tier approach: > > 1) The semantics of markup is specified in a special XML document > which I have previously described and dubbed the "Rosetta Stone". > Obviously not all semantics can be recognized, but those which are of > interest to the accessibility community and other important > stakeholders. In addition, with proper design of the "Rosetta > Stone", the list of semantics can be carefully expanded over time. We do not describe semantics of any kind, since is basically imposible due to our broad interest field. We however wait to obtain a way to describe the scientific markup using standard recommendations -e.g. IUPAC golden book-. Accesibility could be solved via attaching a SMIL or similar file or we believe is better via some generalized 'alt' attribute can be understood by screen readers. There is a role attribute in XML-MAIDEN for that and also a similar approach in next XHTML 2. First approach is being used today in several accesibility programs on mathematics that avoid 'accesible' markup as c-MathML substituting it by a aural rendering. Second approach has minimally worked in HTML at least for images and similar stuff. This would be cheap approach. > 2) Where needed, special stuff is added to CSS so publishers may > override the default presentation for the recognized semantic items > specified in the Rosetta Stone. This might be needed for hypertext > linking and object inclusion, which Ben is working on. And what when presentation needs go beyond current capabilities of CSS? We are adopting CSS but in research we are providing a XML representation for (no XSL-FO) and complementing it with a transformation language (XSLT is too verbose). We waited to use SVG bindings for rendering and basic events whereas semantics is preserved but last notices is that SVG binding has been abandoned by the WG. A related problem is in the serach side. I talked with several scientific oriented search engines and they tend to avoid this. A famous search engine recommend us traditional PDF for they search us. They can obtain certain metadata such as authors datas and so on in an automated scan of the PDF but of course all chemistry, physics, math... are lost. They are not really interested in those issues, therefore, we follow to Mahoma and the mountain. > > > Just some thoughts. > > Jon Noring > > Juan R. Center for CANONICAL |SCIENCE)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |

Cart



