[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: The basic skeleton of an architecture for profiles
I am worn down (but excited), so have not proof-read this email as much as I should. I am posting hoping it makes sense, and to get this out today. I may repost with a clearer version later on if I think that would be useful. This means that while I hope the proposal being made here (an outline for a profiles-based ODF architecture) makes sense (and sounds good), don't anyone break their head over it. I encourage people to read the specific "line-item" descriptions made below and to then vote for each one. +1: you like. +0: you might like but.. 0: you have no opinion at this point in time. -0: you don't really care for very much. -1: you don't like. Then email me directly. I will post results if enough people give opinions. Please provide as many comments as possible on this list (or to me directly if you think that is best). There are many details TBD (to be determined). The more input we get (if in fact this architecture is attractive to enough people), the easier it will be to hash out the details as a group or even individually (..meaning people will propose something major and then try and defend the decisions). There are, for example, XML design decisions to be made before we get into porting over ODF itself to the new arch. Once we have many of the details, we can get started reformulating something like ODF 1.1 into this new architecture. If people don't like anything proposed here (even the concept itself), please complain. There are many components in this proposed profiles-based architecture that deal directly with interoperability. Ultimately, we might package up something to send to the main TC for consideration, as it would be redefining ODF. [See brief discussion way at the end of this email to see how we might be able to retain compat with the existing ODF.] Anyway, the potential for the creation of new and varied profiles will open up a whole new playing field. I would love to include actual text as would be found in the proposed standard, but this will have to wait. I wanted to write up this description so that interested others now have an idea of what I am working on instead of potentially having to wait a long time. Plus, I really want help in pinning down the details. The earlier the better. The alternative would be to spring something on everyone in a week or more, but by then other decisions may have been made. "Release early, release often." Warning, the first few sections are a bit boring. I need to word things better. 1 -- [+1] The key concern for ODF-NG [hereafter, just "ODF"] users will be which profile will define the rules of document handling. Some profiles will be very flexible and allow unknown extensions to be added. Others will be very strict. Others will fall somewhere in between (eg, strict but allow well-known extensions.. or strict except in a few ways). 2 -- [0??] Users guide the life cycle of a document by specifying at the time of creation the one profile that will then define the document rules. It may be possible to also specify extra profiles that may be used to define solely portions of the document or perhaps the whole document but at a later time. Always, the current main (and perhaps only) profile will be found at the root level. Also at root level will be the set of profiles that may replace the main one or apply to some portions. 3 -- [+1] Document Component Definitions [DCD]: A major portion of the ODF standard will consist of an explanation of all the currently known/standard elements and their attributes. There will be "definitions" or references to definitions. Each of these definitions will be numbered and named. There will be numbered and named constraints. The constraints may conflict with some others, but such conflicts will be clear based on their organization, numbering, naming, or through explicit mentioning of such conflicts. 4 -- [+1] There will be named and numbered definitions and constraints in the main ODF section, which lies outside of the DCD. These will be general definitions and constraints that may apply to any element. In the DCD section, each element and attribute will specify those that apply or will redefine any of these definitions or constraints (using the existing global name and number). 5 -- [+1] Such named and numbered definitions and constraints will use accurate and descriptive names. The intention is to allow basic scoping. A name mentioned within a (sub)section has the definition of the nearest enclosing (sub)section. In this sense, names (of definitions or of constraints) are overridden as necessary. The effect is to have the name be usable to refer to a concept that applies to many elements/attributes, but to allow individual overriding in order to change the specific semantics (eg, change the default value or default effect mentioned within the outer definition or constraint, as applicable). These names play a role not too unlike the role played in OOP by the names of members of a class. 6 -- [+1] There are two number spaces: one for definitions and one for constraints [??not sure if this is smart]. Sections of the ODF standard (eg, the main section, the DCD, the section describing profile X, ..) will have a unique section number. The corressponding numbers of the subsections of the ODF standard at the same level of nesting belong to the same number subspace. Thus, items numbered in one subsection may use the same numeral as something different in a different subsection, but are made unique globally through the inherited "outer" number subspaces. In simple words [I got confused, too], a definition might be numbered 5 in various sections, but one would be (1,5), another (2,4.4,5), yet another (2,3.9.2,5). This is just the simple name/ compound name concept of namespaces (but for numbers). [Effectively, the fully qualified number of any numbered item can be designed to serve as the unique XML id whenever that item would be referenced in XML (eg, see profiles description below) because it would specify a unique item within the ODF standard.] 7 -- [+1] Names are just simple. The names ascribed to definitions are within one space, and the names ascribed to constraints are within another [??]. These are each scoped and can be over-ridden. So while a unique number exists whenever there is a need to specify uniquely any numbered/named entity; the name label is used to gather concepts together. [Examples of this crop up further down.] 8 -- [+1] There may be more items that might be numbered besides definitions and constraints, as necessary. These rules would be TBD but will likely work just as numbers and names work for definitions and constraints. 9 -- [+1] Constraints, definitions, and profiles, may be parameterized. This is simply a short-cut way to avoid defining a whole set of permutations based on several enumerated components of such a parameterized definition, constraint, or profile. For example, a constraint might say "xxxxx.. SHALL/SHALL NOT ..xxxxx.. 1-4 ..xxxxx." Rather than to define 8 different constraints, this one would be parameterized. Reference to this constraint (eg, from the XML definition of a profile) would specify the two parameters in order to make it clear exactly which was the constraint being referenced. [These are like templates in C++ and similar languages.] Eg, constraintX(SHALL, 3).. or .. <... <name>constraintX</name><param which=1>SHALL</param><param which=2>3</param>..>. 10 -- [+1] I think constraints and definitions will be given in XML to allow some manipulation (eg, XSLT) and validation of all references to them, in particular, to handle parameterization smartly. [This was mentioned in earlier examples.. partly because I am editing this email and add things out of order.. sorry.] So the contraints and definitions of ODF will have some normative XML that corressponds to those defs and constraints. The XML will be used in profile definitions and will be accessible by ODF consumers and producers. [See next item and further.] 11 -- [+1] Profiles will be defined through XML. Like within the DCD section, a profile may redefine any definition or constraint. Profiles can add their own definitions and constraints (named and numbered, using the basic rules described above). 12 -- [+1] In general, a consumer or producer of ODF documents will have to have support for a profile ahead of time (eg, programmed into the app) in order to know how to interact with any given profile fully. However, there are special cases where not knowing all the details of an unknown profile will still allow interactions. This last goal is a motivation for defining profiles using XML. Furthermore, it's very possible that the app fetching an unknown profile definition will know how to implement every part of the previously unknown profile, meaning it will know how to interact fully with that previously unknown profile (ie, with the document). The app may understand the semantics if, eg, the profile only references standard definitions or standard constraints. The profile would be "new" because of the precise combination of definitions and constraints that define it are not part of any standardized (or known) profile. However, the app would understand what the profile was if it understood all of its components. It's anticipated that profiles will be made frequently by third parties, most notably, by the end users themselves as necessary or desired. An application that understands all the semantics expressed in every part of every element, attribute, and profile definition defined in the ODF standard will have all the information necessary to correctly and unambiguously handle all the ODF standardized profiles AND any new profiles that (as already mentioned) reuse ONLY these standard components. It will thus become a goal of the ODF TC to incorporate as many element definitions, attribute definitions, named/numbered definitions, and named/numbered constraints into the standard as possible as part of their effort to have the market approach as near perfect inter-app interoperability as possible. The more components of profiles that are standardized, the more likely any new profiles will be understood fully by an app. [See item #28 near the bottom of this email for a discussion on OOXML tags.] 13 -- [+1] The ODF standard will likely say very little about what defines a conforming application. Rather, much will be said or implied about the conformance of documents, based on the document's profile. The goal for a user will be to use applications that create, read, and edit the documents as they want profiled, while remaining true to such a profile. 14 -- [+1] An application will be conforming if it handles (creates, reads, or edits) documents according to the "profile statement" at the root level of the document. 15 -- [+0] [At this point, I'm not sure what will make up the "profile statement". The simple design is to just allow a single profile for the lifetime of a document. However, I'd like a std mechanism for specifying more than one possible profile. [See item #2 near top.] 16 -- [+1?] An "edit" means writing to an existing document. It is differentiated from a create/write in that a conforming app may not create a new document using an existing document if it would violate the "profile statement" of any such existing document being used.. unless the application has reason to know the human setting such actions into motion agrees with such a violation. [This needs fixing..] Eg, a user sets up a cron job to do document processing. The tools being used are especially configured (eg, via config file, flags given to cli tool, etc) to delete/discard/ignore the documents being processed in order to create new ones with possibly different profiles. In this case, the new profile must be one that would be acceptable to such a human. An example of what is not allowed is that a user edits a document, and the saved document has a profile statement incompatible with the profile statement that existed before.. unless the user had the editor configured to allow that or accepted the change through a popup or something similar. [This really needs fixing..] "Edit" will be defined in the main section of ODF. 17 -- [+1] A new profile should define certain XSLT fragments. If it does, then apps that are unaware of such a profile will be more likely to be able to do more handling of documents "under" that profile. [Note, the "profile statement" thing is still up in the air and this affects the language I use in this email which will be extra vague at times (eg, "under")....] So remember what is going on. If a conforming app can't process a document according to the document's profile, it must not process in such a way. The SHOULD in this statement above offers a way for newly created profiles to allow a greater number of apps to be able to handle it. This increases interoperability, but due to the nature of what the XSLT is trying to accomplish (to be explained below) and the open-endedness of what can constitute a new future profile, there will likely not be very many hard and fast rules. In short, a profile with "good" XSLT mappings will aid the interoperability of apps that already existed and do not understand certain portions of the new profile. An example: the new profile may be a new version of an existing profile, eg, to be defined in ODF v. 9.9, which uses new semantics or elements not known to the existing app -- perhaps because the elements referenced in the profile were introduced into the ODF spec after the app was written. 18 -- [+1] OASIS or some other group might keep the updated list of elements/attribute/profile definitions. A given version of ODF would only apply to a subset of these (eg, everything existing at the time of the new ODF version). However, the updates and newly added entries would be normative and so conforming apps would be able to use them if the profile allows for it (see below for more on how profiles are made). This design decision exists to help interoperability in the ODF market between ODF version releases, as it is expected new element/attribute/profile definitions will come into existence and maybe into wide use, routinely. Note, here that there is no "mandating" of anything by the standard that arises post the standard. Maintaining updated standardized elements/attribs/profiles just allows those apps that are themselves updated since the most current ODF version to have an increased chance of interoperating with what is in the market. Some users will want to mandate for their use the latest standardized ODF version ALONG WITH the standardized updated list (Ie, the latter would be mandated by the user, not by the older ODF standard). 19 -- [+1] An app that encounters an unknown profile could grab the profile's definition (the XML at the specified URL) in order to attempt to process the document more fully. Assuming the app will not know how to deal with this new profile, it may be possible to still process many parts of the document [marbux, pay attention ;-)]. 20 -- [+1] [...alright marbux, I lack precise details here, but I will try to explain as well as I can. The idea is that the profile author can specify XSLT to be done in a pre-processing or post-processing (or something in between or with other meaning??) on documents to allow them to be handled as if in a different profile. In simple cases, a profile would show how to safely handle documents as per some subprofile of it. It might specify things like "leave all unknown elements and attribs in place.. add new siblings at the front of (or at the end of) the branch ahead of any unknown sibling elements.. [for superprofiles or other that are not otherwise compat:] increment some counter whenever a new element is added so as to satisfy X XPath (the superprofile may have indexing in play or requires that action or uses that as a clue of "dirtiness" so that it reindexes or does something else). An app that knows how to interact with that other profile (the target of the XSLT mappings), could then interact with the document to the extent/scope specified. In short, new profiles can take advantage of the power and automation properties of XSLT to allow clueless apps to process+apply XSLT while the app otherwise works at the understood target profile. Also, any amount of XSLT mapping would help for interop purposes, even if incomplete or very limited. We'd need to standardize the semantics here... Actually, there is a ton to be thought out carefully. HELP! .. Note, this plays into round-tripping in an intelligent way so that the less featureful can be smart about handling the document, even if the superprofile (or not even a superset profile) is created in the future in a way to perhaps be incompatible with the earlier versions.] 21 -- [+1] There are various techniques that will allow the creation of profiles to be more efficient and compact (from the pov of the human designing/defining the profile). These include "parameterized profile groupings". 22 -- [+1] Parameterized profile groupings [PPG]: This is a block scope (an XML element, eg, an XML element of type "profile-grouping") that will include/reference within it elements, attributes, individual definitions, individual constraints, and maybe more things [not sure how these will be referenced.. maybe my name and or number (id which probably will be it's globally unique number)]. The parameterization essentially uses the parameters to determine what is actually in effect inside the grouping (think of it as instantiating an object of the group class perhaps.. or templates.. or whatever you want to think of). [Need to define the XML details of this to handle the parameterization. XSLT may prove useful in defining the parameterization.] This way, we can reuse the groups in other profiles but allowing for modifications (eg, one parameter value might remove some members or change some constraints, etc). PPG within PPG or as sibling nodes should be allowed. [I'll think about this nesting more once we have defined some of the other parts more precisely. The overall goal of PPG's is to allow for space and time savings. Heck, we might just allow PPGs to be named and otherwise be almost like (top-level) profiles. These ideas really need more research....] Note, PPG, like profile, element, and attribute definitions, both are part of the official ODF standard and are XML usable by apps. 23 -- [+1] Informally, profiles will have names that refer to the profile plus list out the specific parameter values used in this instance of the profile. To say profile MyProfile would be enough for unparameterized profiles, but what will likely be needed will be something like MyProfile(xxx,yyy,cccc,sfsdfs,sfsfgggg). Not sure the syntax at this point. We'd use XML anyway, but a short-hand as just described for MyProfile would be useful ..informally. And similar statements could be said about parameterized definitions and about param'd constraints and about anything else param'd. 24 -- [+1] [Not sure how to design the profile XML tags. You want to allow for automatic discovery of as much of the profile's meaning as possible, but any semantic changes newly introduced in the profile (as new normative text, eg, as definition/constraint redefinitions, which would be specified using English prose in many cases) will not be communicable entirely through XML (since there are new semantics, and apps aren't likely to know English grammar). This is one reason why a conforming app, prior to handling the document in some particular way, needs to recognize that specific profile or how it relates to the desired app action (ie, the app designer must code this awareness into the app). Maybe the app can figure out that it can do certain types of actions based on the XSLT frags. EG, the unknown profile is a superprofile and allows certain basic actions (post processed perhaps). Maybe certain ODF standard profile related attributes/elements indicate that the superprofile allows certain conservative basic handling. We might, for example, design the profile XML to include: <profile>...<allows-sibling-added-to-front/> ... </profile> to communicate to an app reading the profile's XML that it can behave according to some rules (eg, add new sibling nodes ahead of any unrecognized nodes) and otherwise handle the document as if it were a document under the particular subprofile chosen. Similarly, the app might learn of (some of) the unknown profile's subprofile's from other info in the unknown profile's XML. The XSLT fragments might map to a profile the app understands or maybe the profile will list all the well-known subprofiles it knows about (eg, this profile might combine a standardized "text processing" profile (perhaps with some parameters adjusted) with a standardized "spreadsheet processing" profile (params adjusted). Then it might list each of these separately as subprofiles, so that apps that recognized either of these standardized subprofiles can work in that subprofile limited context under the prescribed (XSLT or other) rules.. <profile>...<subprofiles>..xxx..yyy...</subprofiles>..</profile>.] 25 -- [+1] Some profiles may allow many extensions, effectively allowing you to replace the profile itself.. or perhaps limited to one of those on a list within the "profile statement" in the root. [See item #2 near the top.] 26 -- [+1] Other profiles will be very strict. They may have a private extension. EG, you like to tag your documents with something special.. maybe supported in your office suite and by your automatic workflow processing through a hand-made plugin or utility processing agent. You allow those extensions but those only. .. Or you may want the business to export or to archive only in some particular very strict ODF standardized profile (of a stable older version of ODF). Using strict profiles doesn't mean you can't upgrade later (a conforming app would not do so without your "permission," as mentioned above in the "edit" definition). It just means you know the range and meaning of everything you might find in your documents at every point in time (or can sue someone if such is not the case ;-) ). Any conforming ODF handler would refuse to add "lock-in" that wasn't allowed in the existing profile. 27 -- [+1] [This section needs rewording..][Defining definitions and constraints will be very interesting. It will likely be here that inter-element or inter-profile rules of engagement will be defined. Any specific profile would have to take care to only use the subset of these that it wants and that are consistent with each other. You want the nondefinition nonconstraint portions of element and attribute definitions to handle things expected to never change. For the most part, this would involve defining the basics of the element semantics. However, it might be possible that all semantics and options will be formalized in a parameterized definition or parameterized constraint. Here we would do things like give the option of MUST vs. MUST NOT or something similar. Another constraint example would be that "all text that is of paragraph nature ["paragraph" would be defined.. perhaps in parameterized form to handle various meanings of the word] MUST/SHOULD/MAY be within text:p." The parameter chosen by a profile that references this last constraint would lead to the MUST, SHOULD, or MAY semantics in play for that profile. So one profile would be strict as far as this specific "constraint" semantics goes, while another would not. Otherwise, these two profiles might be identical in every way. Also, reusing the names of constraints at different scopes (eg, global in main ODF section vs. when defining the element in the DCD vs. at some other scope ??) makes it easy to quickly have a bunch of MUSTs or instead SHOULDs go into play when this global constraint exists and is referenced by the profile. In this way you can create a very extension-friendly "anything goes" profile (or a very strict one) by just referencing the global constraint (via "MAY") at a scope within the profile that would apply as such (MAY) to all the elements that are then named. Otherwise, we'd have to state every single element along with the same sorts of constraints over and over and over.. As an aside, remember that the elements can redefine definitions and constraints within their DCD sections so that it makes sense for that element (so logically you use the same word but the "implementation" is specific to the element.. like over-riding a "draw()" method in a subclass in OOP). This is a separate and distinct issue. It just means that only the local definition exists (the other would make no sense for that element). ..So to recap these two distinct issues: When authoring a profile, you can refer to a global parameterized name (a definition or a constraint, with "MAY" as a param) and it would apply to all elements that would be, eg, within the PPG in scope. NOW, the actual meaning of the def or constraint (param'd by MAY in this case) would be whatever the global definition stated OR ALTERNATIVELY whatever the over-ridden DCD def/constraints redefinition says.] 28 -- [+1] [Marbux (and many others), I think you'll find this comment interesting, though if I did my job and wrote clearly, you'd anticipate it by now.] Hopefully it's clear that OOXML elements and attributes can just be added to the DCD section of this ODF. That may not be a good idea, especially since we'd need maximal precision and awareness of all inter-element behavior, but it is certainly possible and possibly desirable to the extent we can be precise and consistent. I actually suggest that this be attempted. If successful, we can have profiles that use mostly or exclusively these OOXMLish elements. HOWEVER, each profile defines the rules of the road. A user can use an "ODF 1.1 flavored strict" profile which would not include (ever) any OOXML tags. Or the user might not mind using an OOXML version of this. As OOXML is nailed down, perhaps we can add those components to this DCD section. It would in fact be ODF's tags and not the ECMA's OOXML tags, though, hopefully, there would be a large amount of overlap in semantics and syntax. Better to have this ODF/OOXML than only ECMA/OOXML. In the end, it is still just names and labels, but we want a framework where there is control within groups accessible and responsive to the public and a framework that uses a controllable profile architecture. ..As long as the only real (not-even) working implementations of OOXML are closed source, I would not recommend any use of OOXML. Use an a strict profile that is similar to ODF 1.1 or along those lines.] ..or so I hope people will vote that way (or else show why the claims above would be incorrect). That's all folks! [for now] ************** Brief closing discussion about possibly making ODF-NG compatible with the current ODF: [This section needs rewording... btw, lots of things need rewording..] It may be possible to rearchitect ODF 1.1 (1.0, etc) as specified in this proposal (ie, as outlined in this email) so as not to break compatibility too much with existing documents and apps if we carefully design the "ODF 1.1 profile" of ODF-NG. We might, for example, allow all the new elements/attribs that would otherwise necessarily be found in a document according this this proposed arch (eg, an element naming the document profile at the root level) to be missing in a document, but with default meaning to correspond to the existing ODF 1.1 semantics in every way. What I mean is that, for example, if this proposed new ODF might require some new elements, then we might not make them mandatory until a future version perhaps, and state that the absence of that element defaults to having the definition of whatever is necessary to match the existing ODF document. Thus, documents missing one of these desirable elements (eg, the element at root level to specify the document's profile), as would be the case with all existing ODF 1.1 documents, default to the existing ODF 1.1 behavior. For the case of the root profile element, it would mean that a default profile would be in effect when its element is missing in the document and this default profile would match the expected semantics of that document as per the existing ODF (1.1.. 1.0.. etc) standard. That default profile would then have to be created when we define the default profile for ODF-NG 1.1, and it would have to match precisely the existing ODF 1.1 (or 1.0...) standard. Maybe we'd call it ODF-NG 1.1-trans. Anyway, ODF-NG 1.2 would mandate the inclusion of these elements (they wouldn't be optional as they would be in ODF-NG 1.1-trans) if it turned out that this (uncooked) proposal (in fully cooked form) was adopted as ODF 1.2.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]