[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: xml:href, xml:rel and xml:type
You might be surprised to know I support the idea, Peter. In days of old, SGML hypertext systems did not require downtranslation to a gencode such as HTML and it's family of variants. We could create a DTD, create a stylesheet corresponding to it and using the reserved attributes of the specific hypertext engine (what HTML5 really is), display, navigate and retrieve as well as do various limited GUI magicks. My point of view is that types such as xml:href are essentially that: local engine controls for some n of local. Betty Harvey may want to contribute here. I don't think there are many of us left who are familiar with what follows. Why this idea is interesting even today: I'd guess a majority of XML users are not document specialists; they are bits on the wire messengers. OTOH, I am a daily user/applier of one of the oldest still viable type defs for marking up a document class: 40051/2361 with clearly traceable roots to SGML. What follows is to show a case where a consistent application of your proposal could improve effort although it is not a web language application. It creates a file resource for PDF displays and IETM down translations. There is also an extref for references to external documents. The linking information is spread out across the elements, but there is one major cross-reference, the XREF. For discussion's sake, here is the element type declaration with its comment. Note that in 2012, it stills mentions Hytime links, fosi restrictions, etc. I provide this as an example of where progress along certain lines of hypertext development froze in place as we wandered off to do thingsWeb. The restriction to a single entity kept it from being forced to move to the web technology; yet, in practice, the endpoints of most of the proto-links (id/idrefs) are produced in separate entities. Because SGML pushed a link through an entity declaration for indirection, all of the information is there except the hypertext type information. IOW, it has no concept of a URL. <!ELEMENT xref EMPTY> <!ATTLIST xref taskid IDREF #IMPLIED wpid IDREF #IMPLIED stepstart IDREF #IMPLIED stepend IDREF #IMPLIED figid IDREF #IMPLIED itemno CDATA #IMPLIED itemid IDREF #IMPLIED callout CDATA #IMPLIED tableid IDREF #IMPLIED tslocid IDREF #IMPLIED pagelocid IDREF #IMPLIED pretext CDATA #IMPLIED posttext CDATA #IMPLIED termdefid IDREF #IMPLIED security (uc | fouo | c | s | ts ) #IMPLIED restrict NMTOKENS #IMPLIED release NMTOKENS #IMPLIED codeword NMTOKENS #IMPLIED scilevel (0 | 1 ) '0' diglyph NMTOKENS #IMPLIED > <!-- This element and its attributes are for classic cross-references in paper manuals or for simple electronic links. References may be to entire work packages, to maintenance task keywords, to titled procedures, to whole steps, to titled figures, to titled tables, and to page numbers. Consistent use of "xref" makes updating and revisions more manageable. Items to be referenced must have their IDREF "typed" by using the appropriate attribute. "WPID" is the mother attribute; if a reference occurs in a work package other than the current one, a "wpid" must be supplied. Text surrounding the reference, when in paper form, is inserted through attributes "pretext" and "posttext," e.g., "see" and parentheses. The order of expression shall be: pretext?, wpid?, ((taskid, stepstart?, stepend?) | figid | tableid | logicnodeid | tslocid | pagelocid)+, postext?. References to steps or to logic nodes and other troubleshooting locations must also include a reference to either a work package (if different than current location) or a task (if different than the current location within the same WP). If a single step is being referenced, use "stepstart" only ("stepend" will be assumed to be identical); if a range of steps is being referenced, supply both "stepstart" and "stepend" values. Only first-level steps can be referenced, since only they carry a unique identifier. The specific attributes for data types will enable transformations from Hytime clinks to ilinks in the future. --> This is the extref. Note the use of CDATA. !-- following attributes will allow transformations to ilinks in future; FOSI currently supports "wpid" only --> <!ELEMENT extref EMPTY> <!ATTLIST extref docno CDATA #IMPLIED revno CDATA #IMPLIED pretext CDATA #IMPLIED posttext CDATA #IMPLIED wpid CDATA #IMPLIED taskid CDATA #IMPLIED figid CDATA #IMPLIED tableid CDATA #IMPLIED partid CDATA #IMPLIED.... <!-- This element and its attributes are for references to other documents and locations within those documents. Note that the writer may have to supply a value for revision level of the document being referenced. Text surrounding the reference, when in paper form, is inserted through attributes "pretext" and "posttext," e.g., "see" and parentheses; the type of content, such as TS object, supporting information, table or other object, can be inserted through "pretext." --> len -----Original Message----- From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] Sent: Tuesday, April 17, 2012 7:05 AM To: Len Bullard Cc: xml-dev@lists.xml.org Subject: RE: xml:href, xml:rel and xml:type Hi Len, The scope for these attributes is web linking. I can see that there should be a strict constraint on what gets put into the xml namespace. xml codifies a very few but very important things. xml:lang, xml:base and a couple of others. My point of view on this is that html is "big" because it is static and shared. xml needs a bit of this static shared stuff to make it more amenable to certain uses. Goal #1 of XML was to be simple to use on the web. To be simple to use, it needs to have some static, reliably present markup which can be acted on. Web crawlers, to take one example, can't crawl xml, because there is no reliable static markup to identify links in all xml. The existence of xml:href solves that problem. Unless they are Kreskin crawlers they won't know what to do with the xml when they find it. That is what @xml:type is there for. While application/xml does not tell you too much, there are sub sub media types, media type parameters etc to tell you how to process the representation once you retrieve it. Also, it does not have to be xml :-). Finally, applications which use xml on the web need a way to decide / let the client decide what state is the next state for the client. That is what @xml:rel is for. How is this different from xlink? For one thing, it is static shared markup that can be reliably used by the entire community. For another, xlink:type and xml:type are different. xlink:type describes the processing of the link, while xml:type advertises the media type that may be negotiable from the server (no guarantees, after all its the server's resource). Why is xml:lang needed for xml itself? or xml:base for that matter? Why is linking less important? Cheers, Peter > -----Original Message----- > From: Len Bullard [mailto:cbullard@hiwaay.net] > Sent: April 16, 2012 21:03 > To: Rushforth, Peter; 'Simon St.Laurent' > Cc: liam@w3.org; xml-dev@l... > Subject: RE: xml:href, xml:rel and xml:type > > Not to worry, Peter. We've practiced. :) > > Essentially, xml:href adds application semantics to the XML > specification. > XML abhors application semantics in its specification. Adding those > violates the simplicity constraint. Application > specifications are free to > do that. IOW, you are asking the wrong list. Or maybe not, > but the point is, XML doesn't specify XML applications past > what is needed for XML itself. > > > Functional specifications for inter XML linking are a snap. > Functional linking to other media types is built into the web. > > What is the scope for xml:href linking and how does that > differ from what is currently possible with previously > specified technologies? > > One compelling argument for functionally-spec'd XML is > authoring common document type collections, eg, TOCs, typed > indices, figure/table > collections, etc. Tbese are human cultural notation types. > Building those > into a system for use by humans is never wrong, IMHO. > > len > > > > -----Original Message----- > From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] > Sent: Monday, April 16, 2012 6:55 PM > To: Len Bullard; Simon St.Laurent > Cc: liam@w3.org; xml-dev@l... > Subject: RE: xml:href, xml:rel and xml:type > > Not to preach, but I have always felt that respect for what > has been achieved is a good place to start any conversation. > > I am merely asking why some simple steps can't be taken to > move the yardsticks a bit. Not any steps: > the steps I am proposing. > > Cheers, > Peter > ________________________________________ > From: Len Bullard [Len.Bullard@ses-i.com] > Sent: April 16, 2012 4:36 PM > To: Simon St.Laurent; Rushforth, Peter > Cc: liam@w3.org; xml-dev@l... > Subject: RE: xml:href, xml:rel and xml:type > > And so it begins. > > The early HTML people disdained SGML as overbuilt and too > hard to understand because they had yet to understand how and > why it worked for the applications to which it had been > applied. The SGML people returned the disdain but helped them anyway. > > Some decades on, as predicted, attempts to reinvent the early > work on hypertext by the SGML community that evolved into the > XML community continue. At this point, everyone shares A > working system so those > attempts have yet to produce a compelling case. It is somewhat as if > once shown that a Ford A-model could double as a truck, no > one needed anything better. Cab heat would be nice but who > wants to put the fur traders out of business? > > Why no xml:href? How many systems does it take to change a > light bulb? > No one cares while the bulb is lit. > > Why bolt a function-type system onto a syntax standard? > (Linking is a process; not data). > > len > > -----Original Message----- > From: Simon St.Laurent [mailto:simonstl@simonstl.com] > Sent: Monday, April 16, 2012 3:15 PM > To: Rushforth, Peter > Cc: liam@w3.org; xml-dev@l... > Subject: Re: xml:href, xml:rel and xml:type > > > The early XML folks may have found HTML to be not what they > wanted, and seriously lacking in many respects, and the > people driving the HTML conversation today return the disdain > > > What a misfire! > > > ______________________________________________________________ > _________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS to support XML implementation and development. To > minimize spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[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
|