- From: Rivers-Moore, Daniel <daniel.rivers-moore@rivcom.com>
- Date: Thu, 12 Jun 1997 10:25:55 +0100
- To: "XML Working Group (E-mail)" <w3c-sgml-wg@w3.org>
David Durand wrote "Sounds like a great idea for a set of architectural forms that might be used by people with similar problems." I believe there is much to be gained from a stylesheet syntax which uses architectural forms in a big way. Anyone else feel this? I've recently been named joint project leader (with Nigel Shaw of EuroSTEP) in an ISO Preliminary Work Item (under ISO TC184/SC4 - Industrial Data) to look into how SGML and STEP can interoperate. I have from time to time mentioned STEP in my submissions to this forum, and on occasions such as the XML workshop at WWW6 in Santa Clara. There were also presentations on STEP/SGML at SGML Europe 97 in Barcelona. One of the areas I want to look at very seriously is how architectural forms can be used to provide different views of data. The core storage might be highly data-centric, but document-centric, GUI-centric and other-centric views will also be needed. It seems to me that AFs can be a powerful way of achieving this. It seems to me that an architecture (a coherent set of architectural forms) might provide just what is needed - a means of defining a particular subset of the data, presented in a particular way, with particular semantics and behaviour. In short, a rich stylesheet++ or the kind we need. When does work on XML-STYLE begin? I can't wait. Daniel Daniel Rivers-Moore Technical Director, RivCom Lotmead Business Village, Swindon SN4 0UY, UK Tel: +44 (0)1793 790802 Fax: +44 (0)1793 790812 daniel.rivers-moore@rivcom.com (BTW, I think the passage quoted below is from Martin Bryan in response to Andrew Layman - not from Andrew himself) -----Original Message----- From: dgd@cs.bu.edu [SMTP:dgd@cs.bu.edu] Sent: Thursday, June 12, 1997 3:15 AM To: w3c-sgml-wg@w3.org Subject: RE: !BEHAVIOR >At 10:39 11/6/97 -0700, Andrew Layman wrote: >The example that was being discussed, <date>19960527</date>, clearly showed >that what is important is knowing what something is. Unless you understand >the notation used for this date you cannot interpret it. As I said in my >earlier messages, as we cannot use notation for XML elements, and we do not >have access to the lexical typing mechanism provided in the SGML Extended >Facilities Annex, we need some way to distinguish between the following >valid dates: > ><date country=US>01022001</date> ><date country=UK>01022001</date> (30 days later!) ><date country=Isreal culture=Hebrew>20010101</date> (This isn't even in the >same millenium!) ><date country=Isreal culture=Arabic>10022010</date>(This isn't the same as >any of the other dates.) In tradtional SGML, we use attributes and depend on applications to interpret them. We don't have a standard way to do this (which means that you may have to write date-checking code to verify your conforming SGML documents). Leaving things like this is _not_ a showstopper flaw. Most stylesheets need not know the data type of element contents, and most applications that do will require much more structure than a single element, and will use the doctype anyway (though they may have the DTD (and other data formats) compiled in). ><date>01022001</date> is clearly not sufficient to undertand the contents. >You need some qualifier (as I have been forced to do with application >specific attributes in the preceding examples). And it's not something that we desperately need, but something that we would like for some applications. >There are many other cases where you need to invoke some outside interpreter >to be able to understand what an element represents. exactly, and currently it's a processing decision -- if you're not doing _any_ procressing, then syntactic restrictions on the values don't really matter. >Either you need a >notation processor as per SGML or you need some other indirectable mechanism >for identifying how to interpret the data. stylesheet. >What I was suggesting was that >this should be done with a standardized attribute, which I called behaviour >for want of a better name. I do not believe this is about presentation, it >is about being able to make sense of the data when it is not in the same >textual format as the rest of the document. Its about understanding what >something actually is. Sounds like a great idea for a set of architectural forms that might be used by people with similar problems. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________
Received on Thursday, 12 June 1997 05:25:00 UTC