[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oasis-member-discuss] Re: Review of AIR = ASIS, possibly mandatorypolicy?
G. Ken Holman wrote: > At 2006-02-22 17:01 -0800, jon.bosak@sun.com wrote: > >> UBL TC, >> >> Forwarded as requested. >> >> Jon >> ------- Start of forwarded message ------- >> Date: Fri, 17 Feb 2006 16:11:17 -0800 >> From: James Bryce Clark <jamie.clark@oasis-open.org> >> Subject: [chairs] Draft ASIS under review: mandatory policy? Please >> review >> and comment by 1 March >> To: chairs@lists.oasis-open.org > > > Regarding: > > > http://www.oasis-open.org/committees/download.php/16546/ArtifactStandardIdentificationSchemeForMetadata-1.0.1.pdf > > > Line 352 - this is an action item for OASIS staff, not an aspect of > this standard ... the "SHALL" in this jumps out at me as totally > unnecessary. By the time most people have read this document, this > action item should have long been acted on. Unless, of course, I'm > misunderstanding the sentence in which case it should be rewritten. > But, if this updating is a one-time action, is it on the part of those > who maintain the The OASIS Document Templates? When will the > decisions be incorporated into the templates (note in my postscript > below that I've been working on the DocBook XML templates)? A lot of > UBL 2.0 is already in development ... will a change in the templates > while writing a new specification mean that work in progress would > become non-conforming? The templates were updated to (largely) reflect these guidelines quite a while back. And you're right that this is a requirement on OASIS staff that they maintain the templates. Doesn't belong, I think. > Lines 354-386 - I'm not sure what is meant by "consistent tabular > form", especially since it looks like the RFC822-styled prompts and > values (which is distinctly not "tabular" (I interpret this as > systematic aligned rows and columns; the columns are not aligned in > RFC822-styled mail headers). I don't see guidelines as to how this > "consistent tabular form" is to be rendered in various renditions? > Should it be an HTML table? If in a PDF table, with visible cell > borders (perhaps, somewhere in the front matter)? Should it be also > in HTML <meta> elements (I think so; though I don't know how I'll do > this in DocBook)? This should be spelled out in the templates for various forms. > Line 408 - I think ECMA-6 is a poor choice for a 128-byte character > set because of the two ambiguous "alternative graphic character > allocations" (6.4.2) ... I suppose this is covered because the > exclusive list is indicated, so I guess this isn't a problem. Why use > ECMA and not, say, ISO-646? Actually, I guess it has the same issue. > Therefore, why bother citing anything and not just list the characters > ... would this in fact cause problems with a mainframe tool that > happens to be using EBCDIC? The fact that it is the correct ECMA/ISO > characters when it is being mounted in the repository is fine > regardless of how it was written, but given that this is a *naming* > standard and not an *encoding* standard, then just listing the > characters should be sufficient and any mention of character set is > probably unnecessary embellishment. Norm beat this pretty well :-). You're both right. The ECMA names for code points were used (started from the ISO/ASCII spec in conception - Latin-1). > Oh, I just found the reference to <meta> in HTML in section 6.4.1 ... > though it isn't an exhaustive list of the metadata. If ASIS is going > to the trouble of listing all of the metadata components, then perhaps > these should be mandatory XHTML metadata entries as well. Actually, > not *just* XHTML, but for every rendition an example is needed of what > it is to look like ... otherwise, how would I be able to modify the > DocBook XML templates in a conformant fashion? Hmm. Fleshing out the XHTML/etc lists would be an improvement. Personally I'd defer to the template gods, of which you seem to sorta be one. (<--- VERY weak attempt at humor. Sorry, it's late) > Line 532 - Absent here are ZIP and TAR/GZ files (though I don't know > what to do about them) ... I think they should be recognized ... > perhaps have a companion ".txt" file (though I hate the idea of having > information in more than one file)? Though perhaps having a companion > ".txt" file for all binary file types will be both sufficient and > consistent, but line 350 provides a list of required metadata elements > "The following metadata MUST be associated with each Artifact...", so > it would have to be documented that for every binary file (or file > without a human-readable rendition) that one can expect to find a .txt > file with the meta data. That could add a lot of files! Maybe that's justification for not considering archives as artifacts (here we go down a rathole)...metadata needs to be associated for document management and sorting and searching, but I confess that I prefer thinking of them as containers, not as artifacts in their own right. Other comments? > Line 596 - Shouldn't this be a reference to Section 7.1? Yes. > I think it is going to be difficult to get Joe and Jane > StandardsWriter to accurately divine what values for properties in > these guidelines apply to documents they create for their committee > ... could the guidelines require each TC to publish somewhere visibly > in their work pages what the choices are for metadata properties > related to all documents for that particular committee? That way two > people in one TC don't end up making different decisions based on > their respective interpretations of these guidelines. I'm learning > that one really has to spoon feed stuff like this to people who are > made responsible for creating things ... they won't take the energy to > have to interpret administrivia and distract them from their technical > writing. > > So, I then took a look overall at ASIS and I realized that I really > couldn't effectively distill what the important guidelines would be > for, say, the UBL TC or my HISC subcommittee of UBL. > > Consider for example the tree of file with the following directory at > the apex: > > http://docs.oasis-open.org/ubl/cd-UBL-1.0/ > > ... the artifact in that directory has to be named "index.html" in > order to be properly displayed by the server when the directory is > referenced. Does this mean that the directory has the artifact name? > Probably, but there are 244 files in that tree. Are *all* of them > (except the necessary exceptions for the directory "index.html" files) > to be named with these ASIS guidelines? If none of them are used > outside of the context of UBL 1.0, why would the artifact naming > guidelines apply? I can see them applying to the apex directory and > to any ZIP file that would be used out of context of the directory. > That's it! The difference is, when is a committee artifact found > *only* in a given context and when is a committee artifact allowed to > live outside of that context? The apex directory can be found in any > context, so its name follows the artifact naming guidelines. The ZIP > or TAR/GZ packages of the directory can be found in any context, so > its name would also follow the guidelines. And, as above, I suppose > also an associated text file with the metadata for those compressed > packages. > > This would greatly simplify a committee's work. I had the > responsibility for creating the directory at the apex: > > http://docs.oasis-open.org/ubl/cd-UBL-1.0/fs/ > > There are 99 files just in my subtree. BUT my subtree isn't ever > found outside of the context of the UBL 1.0 deliverable, so none of > the artifacts in that subtree would be out of context (or should be > out of context, of course they might be if someone made copies them > without copying the other files, but when they are in context on the > UBL web site inside of the UBL 1.0 deliverable, they are correct). > The burden of going through all 99 files of my subtree and renaming > each and every file to follow the artifact naming guidelines > (examples, graphics, linked specifications, etc.) would deter me from > going through the effort to produce everything that is needed by the > readers. I ended up with 99 files because that tree of hyperlinked > documents and examples is what I felt the reader needed. If I had to > go to so much effort for all 99 files, I would have produced fewer > files without as much information and the reader wouldn't have been as > well served. Let's talk offline. The approach I think you're describing is one that motivated some of the decisions in the guidelines. Groups of help files also take this kind of container arguement. > I believe OASIS has to make the process of writing specifications > *easier* in order to help people with limited time involved in the > already lengthy process of writing to produce something that can be > used. Therefore, the burden should be focused to accomplish the goal > and not so broad as to deter contributions. As I said above, I think > it is sufficient that the burden of identifying artifacts at the apex > directory and any files that might be found outside of the context of > the apex directory. > > Perhaps it is easier than I thought and I was just confused by the > lack of examples. In particular, since I chair two subcommittees and > one task group below the UBL umbrella, are these distinctions > irrelevant? Are my work products just considered UBL work products? The lack of examples was/is a chicken-egg type of problem. Sorry about the current lack; I think that your notion of the context of an identifier is a useful one that might simplify the guidelines. Thanks for your thoughtful comments! bill cox > > > . . . . . . . . . . Ken > > p.s. regarding the templates, I put 33 hours into modifying Norm's > former DocBook guidelines for OASIS standards into a new set of > guidelines to try and help writers using XML, by including all the > sections matching the Word and OOo templates found in: > > http://docs.oasis-open.org/templates > > You can find these new stylesheets and complete publishing package > details in: > > > http://docs.oasis-open.org/templates/DocBook/spec-0.4/oasis-specification-0.4.html > > > In order to try and get my UBL colleagues to use XML to create the > standards documents, I tried to make this environment as turnkey as > possible with detailed examples of what to do. Hopefully by doing so, > members would be more encouraged about writing specification documents > since the environment would produce the desired presentation without > the writer having to think about it. To prove to myself the > environment is functional, I've since used the environment to create > the two work products announced in: > > http://lists.oasis-open.org/archives/ubl/200602/msg00062.html > http://lists.oasis-open.org/archives/ubl/200602/msg00069.html > > So, your decisions impact on me by bringing my latest work to the new > ASIS standard, and I don't see enough information in there to do a > complete job. > > > -- > Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17 > World-wide on-site corporate, govt. & user group XML/XSL training. > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]