Re: More proposals -- and some critical implementation issues
Subject: Re: More proposals -- and some critical implementation issues
From: email@example.com (David G. Durand)
Date: Mon, 30 Dec 1996 13:31:38 -0500
From firstname.lastname@example.org Mon Dec 30 13: 25:08 1996
At 10:16 AM 12/30/96, W. Eliot Kimber wrote:
>At 11:34 AM 12/30/96 -0500, David G. Durand wrote:
>>We can't use default values, because then essentially all browsers will
>>have to fetch DTDs to recognize links...
>Note that as currently defined (and implemented by SP), there are
>defaulting rules for associating element types with architectural forms,
>specifically, an element whose type is the same as a form in the active
>architecture is taken to be of that form. Thus, if we define an XML
>architecture and assume that all XML processors use it, then, assuming
>"ilink" is a form in the architecture, it is unnecessary to specify the
>redundant architecture attribute.
I thought of that but I think it is probably namespace pollution:
especially since an AF name _might_ collide with an element name. And
unlike HyTime, I don't think we should have required markup to turn on
linking functionality, so that the namespace pollution couldn't be turned
>I don't think this is punting--I think it's a natural way to solve the
>problem. There's nothing that says you can't put the architectural
>recognition in your style sheet (you can do it today with DynaText, albeit
>inefficiently, by using the #DEFAULT style and having a buch of switch()
>functions conditioned on form name for the relevant properties).
Punting was really a joke, referring to the fact that we are letting the
DTD slide in a case where it seems to be required. Of course its the
natural way to solve the problem, I suggested it, didn't I?
>So you would disallow attribute renaming? I suppose that's ok, especially
>if we prefix all XML attributes with "-xml-". Renaming is disallowed by
>default--you can choose not to define a renaming attribute, and if you
>don't, no way to rename.
It just seems complicated, and I'm not sure the benefit is worth it. I do
agree that there is benefit, but I could live without it, I think.
>> I need to learn more DSSSL to give stylesheet examples or proposals.
>>Others are welcome to contribute if they have ideas.
>I have it on my to-do list to create DSSSL style sheet that implements the
>InfoMaster architecture. Don't know when I'll get to it, but the basic
>approach would, I think, be to replace the use of the element function with
>a new function, archform, that checks the architectural form just as
>element checks the element type. I haven't had time to work out the
>details of the function, but it can't be that hard.
What I don't understand is how we specify navigation behavior in DSSSL. Is
there a way to attach new "methods" to elements? Functional properties or
lexical closures maybe? If so, we have a great hook...
>Another approach would simply be to apply the style sheet to the
>architectural instance rather than to the base document instance, which you
>can do with Jade by using the -A flag to specify the architecture name.
I think the notion of architectural instances is too confusing, especially
since we are trying for a single abstract syntax tree. An architectural
instance is inherently another abstract syntax tree for the same document,
but accoridng to the architectural form's abstract syntax.
This is a big bunch of stuff to add to every XML processor.
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________